stack frames, so that both stack and frame pointers need to be managed (with fixed-size stack frames, the stack pointer is redundant due to multiplying the stack frame pointer by the size of each frame). This is usually much less costly than calling and anyway. In particular, if the current function contains both calls to alloca and blocks containing variable-length local data then a conflict occurs between alloca's attempts to increase the current stack frame until the current function exits versus the compiler's need to place local variables of variable length in the same location in the stack frame. This conflict is typically resolved by creating a separate chain of heap storage for each call to alloca. The chain records the stack depth at which each allocation occurs, subsequent calls to alloca in any function trim this chain down to the current stack depth to eventually (but not immediately) free any storage on this chain. A call to alloca with an argument of zero can also be used to trigger the freeing of memory without allocating any more such memory. As a consequence of this conflict between alloca and local variable storage, using alloca might be no more efficient than using malloc. System interface Many Unix-like systems as well as Microsoft Windows implement a function called for dynamically allocating stack memory in a way similar to the heap-based malloc. A compiler typically translates it to inlined instructions manipulating the stack pointer, similar to how variable-length arrays are handled. Although there is no need to explicitly free the memory, there is a risk of undefined behavior due to stack overflow. The function was present on Unix systems as early as 32/V (1978), but is not part of Standard C or any POSIX standard. A safer version of called , which reports errors, exists on Microsoft Windows. It requires the use of . gnulib provides an equivalent interface, albeit instead of throwing an SEH exception on overflow, it delegates to when an overlarge size is detected. A similar feature can be emulated using manual accounting and size-checking, such as in the uses of in glibc. Some processor families, such as the x86, have special instructions for manipulating the stack of the currently executing thread. Other processor families, including PowerPC and MIPS, do not have explicit stack support, but instead rely on convention and delegate stack management to the operating system's application binary