1. alloca() is fast but fragile
Many users praise the speed of bump‑pointer stack allocation but warn that it is platform‑dependent, unsafe, and rarely used in production.
“alloca()'s availability and correctness/bugginess is platform dependent, so it probably sees only niche usage since it's not portable.” – stackghost
“alloca() is super useful, but it's also quite dangerous because you can easily overflow the stack.” – spacechild1
“Most C compilers let you use variable length arrays on the stack… if the size is derived from user input then it's exploitable.” – rwmj
2. Alternative allocation patterns are preferred
When the lifetime of data is not tied to a single function call, developers favor arenas, thread‑local buffers, or fixed‑size allocators instead of raw alloca().
“You can just as well pass a heap allocated buffer + size around and allocate by incrementing/decrementing size.” – ozgrakkurt
“Arena allocators are therefore also special use case… you’re willing to defer deallocation of everything to the same time.” – HarHarVeryFunny
“I prefer using an appropriately sized thread_local buffer… Saves you the allocation and does the bookkeeping of having one per thread.” – anematode
3. Stack size limits and overflow risk dominate the discussion
Users repeatedly point out that stack size is a hard limit set by the OS or runtime, and that recursion or large local buffers can easily trigger overflows.
“The alloca() function returns a pointer… If the allocation causes stack overflow, program behavior is undefined.” – stackghost
“With Linux the stack size is a process limit, set with ulimit (default 8 MB). You can even set it to unlimited if you want.” – HarHarVeryFunny
“If you have well defined boundaries, you can move the stack to an arbitrarily large chunk of memory before the recursive call and restore it to the system stack upon completion.” – norir
These three themes—speed vs. safety of alloca(), the prevalence of arena/other allocators, and the practical limits of stack size—capture the core of the conversation.