gcc builtin: alloca

The alloca() function allocates size bytes of space in the stack frame of the caller. This temporary space is automatically freed when the function that called alloca() returns to its caller.

April 6, 2026

gcc gcc_builtin

gcc builtin: alloca


Reqruies

Compiler: gcc 2.8 later

Let's take a look at __builtin_alloca, one of the GCC built-in functions.
The first thing to remember is that many books and posts recommend not using the alloca built-in function for security reasons.

I hope this post helps you clearly understand why.

If you've looked at a lot of open-source code, you've likely encountered __builtin_alloca frequently.
For example, the glibc strdupa macro is defined as follows:


strdupa macro (glibc/string/string.h)
c

__builtin_alloca is a GCC built-in function that allows dynamic memory allocation to use stack space instead of heap.
Therefore, looking at the glibc strdupa code, you can see that free() is not called separately.

Since it is not allocated in the heap space like malloc(), the lifetime of the allocated memory depends on the function scope where the code is included.
Like regular local variables, no separate free() call is needed; the memory is naturally freed just by restoring the stack pointer when returning to the caller function.

As a result, there are advantages in terms of both cpu-time and memory usage compared to calling malloc().

How it works

__builtin_alloca is not called at runtime like a regular function, but is a built-in function that is processed and converted into inline code by GCC at compile-time.
It is used similarly to a macro, but strictly speaking, it is not a macro.

You can see through disassembly that __builtin_alloca is converted into other code by GCC.


builtin_alloca replacement example
bash

You can see that it is not a standard function call like callq __builtin_alloca, but rather directly manipulates the stack layout (e.g., sub %rax, %rsp).

This built-in allocates memory dynamically, but is mainly used where it is guaranteed to be used only temporarily within a specific function, like a local variable.

Let's take a look at the GCC documentation.


Built-in Function: void *__builtin_alloca (size_t size)
Doc
The __builtin_alloca function must be called at block scope.
The function allocates an object size bytes large on the stack of the calling function. The object is aligned on the default stack alignment boundary for the target determined by the BIGGEST_ALIGNMENT macro.
The __builtin_alloca function returns a pointer to the first byte of the allocated object.
The lifetime of the allocated object ends just before the calling function returns to its caller.
This is so even when __builtin_alloca is called within a nested block.
https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Other-Builtins.html#Other-Builtins

I haven't looked at the GCC code in detail, but it's a built-in that has existed since GCC 2.8.

Sample code

Let's briefly check how to use it through sample code.


sample code - alloca.c
c


Execution Result
bash


assembly - x86_64 AT&T
bash

The memory alignment routine was also added by the compiler, but the most important part is that only the stack space is temporarily expanded to secure memory, and upon return, the stack pointer is restored to its original state through leaveq and retq, naturally freeing the memory without a separate free() call.

Scope

The GCC documentation explains scope as follows:

The lifetime of the allocated object ends just before the calling function returns to its caller

In glibc 1.09, __builtin_alloca was defined as alloca to shorten the long name.


__builtin_alloca is defined as alloca in glibc/stdlib/alloca.h
c

Therefore, by including alloca.h, you can conveniently use it through the alloca macro name.

However, personally, I think it's more intuitive to express it without omitting the __builtin prefix to clearly show that the function is not a regular function called at runtime, but a built-in substituted at compile time.

Of course, this is a matter of coding style, so in collaborative projects, you should follow the established Coding Rules.

It looks similar to VLA (Variable-Length Array), which is supported in C99 and has its size determined at runtime instead of compile time, but the lifetime of the allocated memory is different.

While the lifetime of VLA is block scope, alloca is function scope.
In other words, VLA cannot be used in the following situations:


VLA vs alloca lifetime example
c

Security concerns

As mentioned earlier, VLA or alloca, which allocate variable-sized memory on the stack, can be security risks, so many media outlets recommend avoiding their use, and I agree.
Allocating memory whose size is dynamically determined on the stack can cause a stack overflow, which can be a target for serious security vulnerability attacks.

Also, if a negative allocation length is passed, it is interpreted as a very large positive number (size_t), causing the stack pointer to become corrupted and the program to behave in unintended ways.

Furthermore, since the lifecycle is different from the malloc/free pattern widely used as the standard for dynamic allocation in C, it can cause great confusion for developers unfamiliar with alloca's memory management techniques.

alloca is not standard - it is a GNU extension

For these reasons, the Linux kernel project also made significant efforts to remove VLAs within the codebase, and as a result, successfully removed all VLA usage in kernel version 4.20.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kills-The-VLA

The GNU documentation explains the advantages of alloca as follows:


Advantages-of-Alloca
Doc

Using alloca wastes very little space and is very fast. (It is open-coded by the GNU C compiler.)

Since alloca does not have separate pools for different sizes of blocks, space used for any size block can be reused for any other size. alloca does not cause memory fragmentation.

Nonlocal exits done with longjmp (see Non-Local Exits) automatically free the space allocated with alloca when they exit through the function that called alloca. This is the most important reason to use alloca.
https://www.gnu.org/software/libc/manual/html_node/Advantages-of-Alloca.html#Advantages-of-Alloca

The disadvantages are explained as follows:


Disadvantages-of-Alloca
Doc

If you try to allocate more memory than the machine can provide, you don't get a clean error message. Instead you get a fatal signal like the one you would get from an infinite recursion; probably a segmentation violation (see Program Error Signals).

Some non-GNU systems fail to support alloca, so it is less portable. However, a slower emulation of alloca written in C is available for use on systems with this deficiency.
https://www.gnu.org/software/libc/manual/html_node/Disadvantages-of-Alloca.html#Disadvantages-of-Alloca

Safer alloca

__builtin_alloca_with_align was added in GCC 4.7, and __builtin_alloca_with_align_and_max was added in GCC 8.1.
This allows setting a maximum size (max_size) or alignment (align) to use alloca more safely.

These are simple additions, so please check the documentation.


Other-Builtins
Doc

Built-in Function: void *__builtin_alloca_with_align (size_t size, size_t alignment)

Built-in Function: void *__builtin_alloca_with_align_and_max (size_t size, size_t alignment, size_t max_size)
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

To use alloca more safely, a compilation option to check the maximum size of alloca at compile time was added in GCC 7.0.
You can also check whether alloca is being used in the code.

-Walloca-larger-than, -Walloca ...

Conclusion

If you inevitably have to use alloca, you must pay special attention to checking the upper limit of the allocation size and the range of argument values.

In particular, be careful when using alloca inside an inline function, as it can cause unintended stack leak issues.
The reason is simple: the point of memory deallocation is not the inline function itself, but when the parent function (caller) that called and expanded (inlined) it returns at runtime.

In other words, if a specific inline function is continuously called within a loop, etc., memory will be cumulatively allocated within that stack frame, which can lead directly to a fatal stack overflow.

Nextgcc options: -fsigned-char