malloc(3c) 맨 페이지 - 윈디하나의 솔라나라


맨 페이지 이름


Standard C Library Functions                                        malloc(3C)

       malloc,  calloc, free, memalign, realloc, valloc, alloca - memory allo‐

       #include <stdlib.h>

       void *malloc(size_t size);

       void *calloc(size_t nelem, size_t elsize);

       void free(void *ptr);

       void *memalign(size_t alignment, size_t size);

       void *realloc(void *ptr, size_t size);

       void *valloc(size_t size);

       #include <alloca.h>

       void *alloca(size_t size);

       The malloc() and free() functions  provide  a  simple,  general-purpose
       memory allocation package. The malloc() function returns a pointer to a
       block of at least size bytes suitably aligned for any use. If the space
       assigned by malloc() is overrun, the results are undefined.

       The  argument to free() is a pointer to a block previously allocated by
       malloc(), calloc(), or realloc(). After free() is executed, this  space
       is made available for further allocation by the application, though not
       returned to the system. Memory is returned to the system only upon ter‐
       mination  of  the  application.  If  ptr  is  a null pointer, no action
       occurs. If a random number is passed to free(), the results  are  unde‐

       The calloc() function allocates space for an array of nelem elements of
       size elsize. The space is initialized to zeros.

       The memalign() function allocates size bytes on a  specified  alignment
       boundary and returns a pointer to the allocated block. The value of the
       returned address is guaranteed to be an even multiple of alignment. The
       value  of  alignment must be a power of two and must be greater than or
       equal to the size of a word.

       The realloc() function changes the size of the block pointed to by  ptr
       to  size bytes and returns a pointer to the (possibly moved) block. The
       contents will be unchanged up to the lesser of the new and  old  sizes.
       If  the new size of the block requires movement of the block, the space
       for the previous instantiation of the block is freed. If the  new  size
       is larger, the contents of the newly allocated portion of the block are
       unspecified. If size is 0, the space pointed to by ptr is freed  and  a
       newly allocated block is returned, as if by a call to malloc(0). If ptr
       is NULL, realloc() behaves like malloc() for the specified size.

       The valloc() function has the same effect as malloc(), except that  the
       allocated memory will be aligned to a multiple of the value returned by

       The alloca() function allocates size bytes of space in the stack  frame
       of  the caller, and returns a pointer to the allocated block. This tem‐
       porary space is automatically freed when the  caller  returns.  If  the
       allocated block is beyond the current stack limit, the resulting behav‐
       ior is undefined.

       On SPARC M7 and later systems, malloc() supports the  ADIHEAP  security
       extension. When the ADIHEAP security extension is enabled for the call‐
       ing program, malloc() and related functions will use the SPARC Applica‐
       tion  Data  Integrity  APIs to provide buffer overrun detection; out of
       bounds pointer detection; and detection of use after  free,  use  after
       reallocation,  and  stale pointer errors. For more information, see the
       adi(3C) and sxadm(8) man pages.

       By default, when ADIHEAP is enabled, ADI version  mismatches  on  store
       instructions produce a disrupting trap, which means that the associated
       SIGSEGV signal may be delivered some number of instructions  after  the
       offending store, and that may make it more difficult to debug some pro‐
       grams. To force a precise trap for  ADI  version  mismatches  on  store
       instructions, set the environment variable _LIBC_ADI_PRECISE. The value
       to which it is set is irrelevant; what matters is the existence of  the
       environment  variable.  Setting  _LIBC_ADI_PRECISE might have a perfor‐
       mance impact; the magnitude of the impact depends on the percentage and
       pattern  of  the store instructions in the program. Because of that, it
       is recommended that _LIBC_ADI_PRECISE be set only  for  debugging  pur‐

       ADI  version  mismatches  on load instructions always produce a precise
       trap, with no additional impact on performance.

       Upon successful completion, each of the allocation functions returns  a
       pointer to space suitably aligned (after possible pointer coercion) for
       storage of any type of object.

       If there is no available memory, malloc(), realloc(), memalign(),  val‐
       loc(),  and  calloc()  return  a null pointer. When realloc() is called
       with size > 0 and returns NULL, the block pointed to  by  ptr  is  left
       intact.  If  size,  nelem,  or  elsize is 0, either a null pointer or a
       unique pointer that can be passed to free() is returned.

       If malloc(), calloc(), or realloc() returns unsuccessfully, errno  will
       be set to indicate the error. The free() function does not set errno.

       The malloc(), calloc(), and realloc() functions will fail if:

       ENOMEM    The  physical limits of the system are exceeded by size bytes
                 of memory which cannot be allocated.

       EAGAIN    There is not enough memory available to allocate  size  bytes
                 of memory; but the application could try again later.

       Portable  applications  should  avoid using valloc() but should instead
       use malloc() or mmap(2). On systems with a large page size, the  number
       of successful valloc() operations might be 0.

       These  default  memory  allocation  routines are safe for use in multi‐
       threaded applications but are not scalable. Concurrent accesses by mul‐
       tiple  threads  are  single-threaded  through the use of a single lock.
       Multithreaded applications that make heavy use of dynamic memory  allo‐
       cation  should be linked with allocation libraries designed for concur‐
       rent access, such as libumem(3LIB) or  libmtmalloc(3LIB).  Applications
       that  want  to  avoid using heap allocations (with brk(2)) can do so by
       using  either  libumem(3LIB)  or  libmapmalloc(3LIB).  The   allocation
       libraries libmalloc(3LIB) and libbsdmalloc(3LIB) are available for spe‐
       cial needs.

       Comparative features of the various allocation libraries can  be  found
       in the umem_alloc(3MALLOC) manual page.

       See attributes(7) for descriptions of the following attributes:

       tab()  box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
       TRIBUTE VALUE _ Interface StabilityCommitted _ MT-LevelSafe _ Standard‐
       See below.

       For  malloc(),  calloc(),  free(),  realloc(),  and valloc(), see stan‐

       brk(2), getrlimit(2), adi(3C), libadimalloc(3LIB),  libbsdmalloc(3LIB),
       libmalloc(3LIB),  libmapmalloc(3LIB), libmtmalloc(3LIB), libumem(3LIB),
       umem_alloc(3MALLOC), watchmalloc(3MALLOC), attributes(7), standards(7),

       Undefined  results will occur if the size requested for a block of mem‐
       ory exceeds the maximum size of a process's heap, which can be obtained
       with getrlimit(2)

Oracle Solaris 11.4               13 Jun 2018                       malloc(3C)
맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.