4 ms·
> Therefore, data whose size cannot be determined at compile time or whose size can be changed cannot be safely placed on the stack. "someone is wrong on the i
by evgpbfhnr 2y ago
> Therefore, data whose size cannot be determined at compile time or whose size can be changed cannot be safely placed on the stack.
"someone is wrong on the internet" -- afaik VLA (variable length arrays) can go on the stack just fine, at the very least stuff like alloca is just that. It's just a matter of incrementing the stack pointer by a variable length before calling the next function.
The problem with stack and large objects is that a program has no standard way of knowing how large the stack is, at some point if you grow the stack too much you'll start hitting another memory region used for something else (another thread's stack, some library mapping, or the heap); and alloca failure mode is basically just "bad things happen" so it's not recommended... But it's definitely not a "known at compile time" problem.
- gpderetta 2y agokey being "safely placed". VLAs and allocas keep being deprecated everywhere as they are a time bomb. In practice you need safe upperbound for VLAs and alloca, so you might as well just allocate the upper bound as a fix size array outright. If you do not initialize the array, there is no real additional cost other than the additional stack probes. On GCC at least, alloca and VLAs disable some optimizations (like inlining) so it is really a wash. If you need truly unbounded size allocations, you need an heap fallback anyway.