From 52ec6097603e54d510e8fb7550d34d5c03a4ef8a Mon Sep 17 00:00:00 2001 From: Mattias Andrée Date: Sat, 17 Oct 2015 21:05:06 +0200 Subject: info: alloca MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Mattias Andrée --- doc/info/chap/memory-allocation.texinfo | 66 ++++++++++++++++++++++++++++++++- 1 file changed, 65 insertions(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/info/chap/memory-allocation.texinfo b/doc/info/chap/memory-allocation.texinfo index 3d59634..a9d3c7e 100644 --- a/doc/info/chap/memory-allocation.texinfo +++ b/doc/info/chap/memory-allocation.texinfo @@ -233,6 +233,20 @@ void function(size_t n) Both of these allocation-methods are both automatic and dynamic. +@cpindex Memory exhaustion +Memory allocation functions return @code{NULL} if +the process cannot allocate more memory. However, +under typical configurations of the operating system +kernel, memory allocation functions can return +succesfully, even if the system's memory is exhausted. +The process's virtual address space is not exhausted, +so it thinks it can allocate the memory, but the machines +memory is exhausted, so once the process tries to write +to the memory, the kernel cannot map the virtual address +to a real address. When this happens the process is +killed by a @code{SIGSEGV}@footnote{Segmentation +violation, also known as segmentation fault.} signal. + @menu * The alloca function:: Dynamically allocate automatically freed memory. @@ -248,7 +262,57 @@ and dynamic. @node The alloca function @section The @code{alloca} function -TODO +@cpindex Dynamic allocation +@cpindex Automatic allocations +@cpindex Stack-allocations +@fnindex alloca +The function @code{void* alloca(size_t n)} appears +on multiple systems: 32V, @sc{PWB}, @sc{PWB}.2, +3@sc{BSD}, 4@sc{BSD}, and @sc{GNU}. It has been +added to @command{slibc}, without require on +feature-test macros, despite not being standardised +(for instance, it does not appear in @sc{POSIX}). +This function is however not portable, and will not +be made available if @code{_PORTABLE_SOURCE} or +@code{_LIBRARY_HEADER} is defined. + +@code{void* alloca(size_t n)} is similar to the +function @code{malloc}. It allocates a contiguous +space of usable memory of @code{n} bytes, and +returns a pointer, which points to the beginning +of the allocated memory. However, the allocate +appears on the stack rather than the heap, and +it automatically deallocated when the function +whence the call to @code{alloca} was made. Be +cause if this, @code{alloca} is implemented as +a macro --- using an intrinsic function provided +by the compiler --- rather than as a function. + +You must not try to free the memory explicitly, +with a function like @code{free}, or resize it +with a function like @code{realloc}. Just like +arrays and pointers to automatic variables, +memory management functions cannot operate +memory allocated with @code{alloca}. + +@cpindex Memory exhaustion +Unlike @code{malloc}, @code{alloca} does not detect +memory exhaustion, thus it will never return +@code{NULL}. However, it is likely that the process +will receive @code{SIGSEGV}@footnote{Segmentation +violation, also known as segmentation fault.} if it +tries to access memory that could not be allocated, +or, depending on the kernel's configuration, before +it returns. + +Undefined behaviour may be invoked if @code{alloca} +is called within a function call. The behaviour +depends on the machine, the compiler, and +optimisations. You should avoid code similar to +@example +#define strdupa(string) \ + strcpy(alloca((strlen(string) + 1) * sizeof(char)), string) +@end example -- cgit v1.2.3-70-g09d2