Go to main content

man pages section 3: Basic Library Functions

Exit Print View

Updated: Thursday, June 13, 2019
 
 

memalign(3C)

Name

malloc, calloc, memalign, realloc, reallocarray, valloc, free, malloc_usable_size - memory allocator

Synopsis

#include <stdlib.h>

void *malloc(size_t size);
void *calloc(size_t nelem, size_t elsize);
void *memalign(size_t alignment, size_t size);
void *realloc(void *ptr, size_t size);
void *reallocarray(void *ptr, size_t nelem, size_t elsize);
void *valloc(size_t size);
size_t malloc_usable_size(void *ptr);
void free(void *ptr);

Description

These functions provide a simple, general-purpose memory allocation package. If the space assigned by any of the memory allocation functions is overrun, the results are undefined, except as noted in the ADI INTERACTION section.

The malloc() function allocates and returns a pointer to a block of at least size bytes suitably aligned for any use. The initial contents of the memory in this block are unspecified.

The calloc() function allocates space for an array of nelem elements of size elsize and returns a pointer to the allocated block. 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 reallocarray() function behaves like realloc() except that the new size of the allocation will be large enough for an array of nelem elements of size elsize. If padding is necessary to ensure proper alignment of entries in the array, the caller is responsible for including that in the elsize parameter.

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 sysconf(_SC_PAGESIZE).

The argument to free() is a pointer to a block previously allocated by one of these memory allocation functions. After free() is executed, this space is made available for further allocation by the application. Memory might not be returned to the system until termination of the application. If ptr is a null pointer, no action occurs. If ptr is not a null pointer, and not a value previously returned by one of these memory allocation functions, or if the same non-null value is passed more than once per allocation, the results are undefined.

The malloc_usable_size() function returns the number of bytes of allocated memory in a block at ptr that was allocated by one of these memory allocation functions and which has not yet been freed. The size returned may be larger than the original size requested, though programs should not rely on being able to use more bytes than originally requested. This will not include the size of any internal bookkeeping data, red zones, or other memory that the program cannot safely read or write as part of this block. If ptr is a null pointer, 0 is returned. If ptr is not a null pointer, and not a value previously returned by one of these memory allocation functions that has not yet been freed, the results are undefined - the function may return 0 and set errno to EINVAL if it successfully detects an invalid pointer, but it is not guaranteed to detect all possible invalid pointers and may return an incorrect size or cause a program fault.

ADI INTERACTION

On Oracle SPARC systems with support for the Application Data Integrity (ADI) feature the default set of malloc() functions support the ADIHEAP security extension. When the ADIHEAP security extension is enabled for the calling program, malloc() and related functions will use the SPARC Application Data Integrity APIs to provide detection of buffer overruns, out of bounds pointers, use after free errors, use after reallocation errors, and stale pointer errors. For more information, see the adi(7) and sxadm(8) manual 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 programs. 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 performance 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 purposes.

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

Return Values

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 size, nelem, or elsize is 0, the allocation functions return a unique non-null pointer that can be passed to free(). These pointers should not be dereferenced.

If there is not enough memory available, the allocation functions return a null pointer and set errno.

When realloc() or reallocarray() return NULL, the block pointed to by ptr is left intact. If size, nelem, or elsize is 0, the block pointed to by ptr is freed, and a unique pointer that can be passed to free() is returned.

If one of the allocation functions returns unsuccessfully, errno will be set to indicate the error. The free() function does not set errno.

The malloc_usable_size() function returns a size (which may be 0) on success, and 0 on failure. In the event of failure, errno will also be set.

Errors

The memory allocation functions will fail if:

ENOMEM

The limits of the system are exceeded by the requested amount of memory, which cannot be allocated.

EAGAIN

There is not enough memory available at this point in time to allocate the requested amount of memory; but the application could try again later.

The calloc() and reallocarray() functions will also fail if:

ENOMEM

The multiplication of the nelem and elsize parameters would lead to an integer overflow.

The malloc_usable_size() function may fail if:

EINVAL

The pointer provided is not a valid pointer returned by one of the memory allocation functions described on this page.

Usage

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

Memory allocated by these functions may be on pages with the PROT_EXEC access protections disabled to block execution of machine instructions, depending on the system settings for NXHEAP in sxadm(8) and any –z sx=nxheap options that were passed to ld(1) when linking the application. These settings may be overridden for individual pages by calling mprotect(2).

These default memory allocation routines are safe for use in multithreaded applications but are not scalable. Concurrent accesses by multiple threads are single-threaded through the use of a single lock. Multithreaded applications that make heavy use of dynamic memory allocation should be linked with allocation libraries designed for concurrent 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 special needs. Further comparative features of the various allocation libraries can be found in the ALTERNATIVE IMPLEMENTATIONS section below.

Mixing multiple memory allocation libraries in a single program is not expected to work well. Passing a pointer allocated by one library to the free(), realloc(), or malloc_usable_size() functions from another library is undefined, and may cause memory corruption or program faults.

Attributes

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

ATTRIBUTE TYPE
ATTRIBUTE VALUE
Interface Stability
Committed
MT-Level
Safe
Standard
See below.

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

INTERFACES
APPLICABLE STANDARDS
  • malloc()
  • calloc()
  • realloc()
  • free()
  • C89 through C11,
  • POSIX.1-1990 through 2008,
  • SUS through SUSv4,
  • XPG1 through XPG7
  • valloc()
  • SUS through SUSv2,
  • XPG4v2 through XPG5
  • malloc_usable_size()
  • memalign()
  • reallocarray()
None

See Also

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

Warnings

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

ALTERNATIVE IMPLEMENTATIONS

The functions described in this page are all exported from libc.so.1 with the NODIRECT flag to prevent direct bindings and allow easy interposition of alternative implementations, either by linking to another library or by using the LD_PRELOAD functionality of the runtime linker, ld.so.1(1). Alternative implementations cannot be dynamically loaded with dlopen(3C) during runtime because there must be only one manager of the process heap.

Oracle Solaris includes a number of alternative implementations with different characteristics that make them suitable for usage in various scenarios. The following list compares the features of the malloc(3C), bsdmalloc(3MALLOC), libadimalloc(3LIB), malloc(3MALLOC), mapmalloc(3MALLOC), mtmalloc(3MALLOC), libumem(3LIB), and watchmalloc(3MALLOC), libraries.

  • The default malloc(3C) and malloc(3MALLOC) functions use a single global lock to ensure that only one thread at a time can allocate memory. The libumem(3LIB), libadimalloc(3LIB), and mtmalloc(3MALLOC) functions support concurrent allocations. The bsdmalloc(3MALLOC) functions have no support for concurrency.

  • The bsdmalloc(3MALLOC) functions afford better performance but are space-inefficient and not thread-safe. They also maintain compatibility with historical semantics from the BSD environment of SunOS 4 releases.

  • The malloc(3MALLOC) functions are space-efficient but have slower performance.

  • The default malloc(3C) functions are a trade-off between performance and space-efficiency.

  • The mtmalloc(3MALLOC) functions provide fast, concurrent malloc() implementations that are not space-efficient.

  • The libumem(3LIB) functions provide a fast, concurrent allocation implementation that in most cases is more space-efficient than mtmalloc(3MALLOC).

  • The libumem(3LIB), libadimalloc(3LIB), mtmalloc(3MALLOC), and watchmalloc(3MALLOC) libraries provide additional support for debugging memory allocation problems.

  • The default malloc(3C) functions, the libumem(3LIB) functions, and the libadimalloc(3LIB) functions offer the option to provide detection of buffer overruns, out of bounds pointers, stale pointers, and use after free errors using the SPARC Application Data Integrity (ADI) feature. These are enabled by default in libadimalloc, while the others only use these features if the ADIHEAP security extension is enabled as described above. Using these features reduces the space efficiency of allocations with these libraries, and may affect application performance.

  • Most of these implementations use heap allocations managed with the brk(2) system call. The libmapmalloc(3LIB) functions instead use mmap(2) to reserve memory to allocate blocks from, allowing applications to use brk(2) for their own purposes. libumem(3LIB) allocates heap memory by default, but offers an option to use mmap(2) instead, as described in the umem_alloc(3MALLOC) manual page.

When implementing an alternative implementation of these functions for general use by other software, a library must provide at least all of the following:

  • calloc()
  • free()
  • malloc()
  • malloc_usable_size()
  • memalign()
  • realloc()

Replacements for the following may be optionally provided:

  • reallocarray()
  • valloc()

If replacements are not provided, the default implementations of reallocarray() and valloc() will call the realloc() and memalign() functions provided by the active allocation library.

Replacements for the functions aligned_alloc(3C) and posix_memalign(3C) should not be provided by alternative implementations. These functions are provided by libc(3LIB), and call the memalign() and malloc() functions provided by the active allocation library. They are therefore compatible with all alternative malloc implementations that fully support those functions.

Additional functions may be required in the future as APIs evolve.

HISTORY

The malloc_usable_size() function was defined in GNU libc 2.0, and was added to Oracle Solaris in the Oracle Solaris 11.4.10 release.

The reallocarray() function was defined in OpenBSD 5.6, and was added to Oracle Solaris in the Oracle Solaris 11.4.10 release.