Hacker News new | ask | show | jobs
by einpoklum 31 days ago
I find variable-length arrays (i.e. arrays whose length is defined at run-time and typically live on the stack) to be kind of dangerous, and try to avoid them, even in C.
3 comments

A type of VLA I would like to see more of in C code however, is variable-length array parameters (void func(int n, int arr[n]);) and array pointers (int (*my_array)[n];).

Compilers can often do some static bounds-checking of such arrays. But because those features had been introduced together with variable-length array stack variables , people have lumped them all together and thus shunned these features that could otherwise have added safety.

BTW, one thing you should never do is use variable-length array declarations and alloca() in the same function. As VLA variables have scope life-time and allocas have function life-time they are not compatible — and allocations could overlap. Yet, not all compilers (/versions) that support both warn when they are used together.

The array at the end of the struct is not a VLA on the stack. When you allocate the struct, you add enough extra to hold the contents of the array. VLAs on the stack are pretty much universally considered a bad idea, as far as I can tell.
Why do you think they are dangerous?
If the VLA size is not controlled it gives an attacker a primitive for arbitrarily shifting the stack pointer. There isn’t any spec for what is a reasonable limit on a VLA size. https://dotat.at/@/2010-01-22-coroutines-in-less-than-20-lin...
Yes, attacker controlled size without limit is bad (and this is also true for heap allocations). For VLAs there is -Wvla-larger-than that can be used to ensure there is a hard limit. To understand the risks of VLAs one also has to compare it to the alternatives. A fixed-size array on the stack is basically always worse. alloca is substantially worse. heap allocation may be a bit better, but also much slower.