On 2024-10-21 22:38, Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> A. VLAs make code less safe, due to problems with stack overflow and
> related issues. There is no portable way for a program to detect and
> recover from memory exhaustion, and indeed in many implementations
> (including default GNU, if I'm not mistaken) the system does not even
> detect memory exhaustion reliably - the program merely has undefined
> behavior instead. This dangerous behavior is particularly important in
> multithreaded apps where each thread has a relatively small stack.
Is that any worse with VLAs than with `alloca'?
No, and that is why many GNU programs also avoid alloca.
A common strategy is to allocate a small, fixed size array on the stack
and use it in the normal case, falling back on malloc+free only in the
rare case when the stack array is too small. This sort of approach is
used extensively in the GNU C library and in core GNU utilities. In
these applications alloca would typically be too dangerous, just as
stack-allocated VLAs would be.
> B. They make code a bit slower.
Slower than what alternative?
Slower than not supporting VLAs at all. The generated code doesn't need
a separate register for the frame base vs the stack top, needn't save
and restore the stack top when entering and exiting blocks, and so forth.
This efficiency argument holds less water nowadays; I mentioned it only
because others have. The main argument against stack-allocated VLAs is
safety. It's unfortunate as they'd be nice to use otherwise.
