After removing all the calls to malloc and calloc from our code for an embedded system, I was surprised to find that malloc was still being linked in. The call graph pointed me to a function which had no explicit *alloc calls, and no calls to any library functions that might allocate, like strdup.
I had to look at the generated assembly to realize that it was due to an inlined function which contained a VLA.
I thought VLAs had to be stack-allocated. Is this compiler broken?
There is no requirement that VLAs be allocated from the stack (the language standard doesn't even mention stacks or heaps). The only requirement is as follows:
6.2.4 Storage durations of objects
...
7 For such an object that does have a variable length array type, its lifetime extends from the declaration of the object until execution of the program leaves the scope of the declaration.35) If the scope is entered recursively, a new instance of the object is created each time. The initial value of the object is indeterminate.
35) Leaving the innermost block containing the declaration, or jumping to a point in that block or an embedded block prior to the declaration, leaves the scope of the declaration.
Given this, it makes sense to allocate from the stack, but for very large objects this may not be possible, and such an object may be allocated from the heap or some other memory segment instead. The bookkeeping is up to the implementation.
No, they don't have to be stack-allocated. I would use alloca if you want it to be on the stack.
Source 1: https://stackoverflow.com/a/2035292/283342
Secondly, VLA is normally allocated on stack, but because of its variable size, in general case its exact location in memory is not known at compile time. For this reason the underlying implementation usually has to implement it as a pointer to a memory block. This introduces some additional memory overhead (for the pointer), which is again completely insignificant for the reasons described above. This also introduces slight performance overhead, since we have to read the pointer value in order to find the actual array. This is the same overhead you get when accessing malloc-ed arrays (and don't get with the named compile-time-sized arrays).
Source 2: https://en.wikipedia.org/wiki/Variable-length_array
One problem that may be hidden by a language's support for VLAs is that of the underlying memory allocation: in environments where there is a clear distinction between a heap and a stack, it may not be clear which, if any, of those will store the VLA.
