Is it required that a C Variable Length Array is allocated from the stack?

Question

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?

In this case, the size parameter was a `uint8_t`, so worst case was 256 bytes, roughly 1/5th the stack. — AShelly, Oct 08 '15 at 16:09
If there's no chance for stack overflow (I mean real one :-), why not to use simply worst case, i.e. some `char arr[256]` instead of VLA? — Matt, Oct 08 '15 at 16:26
I did change it to fixed. The main point of the question is to debunk the [common](http://stackoverflow.com/q/22530363/10396) [assumption](http://stackoverflow.com/q/15131941/10396) [that VLAs are](http://stackoverflow.com/a/2034739/10396) [always stack](http://stackoverflow.com/a/20295770/10396). — AShelly, Oct 08 '15 at 16:57

score 9 · Accepted Answer · answered Oct 08 '15 at 15:53

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.³⁵⁾ 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.

Most real implementations just fault if you exceed their stack-size limits by making a too-large VLA, or a sequence of them in a chain of function calls. Only use VLAs if you *know* the size will be limited, and even then be careful in non-leaf functions. An implementation would be *allowed* to save you from yourself by allocating VLAs separately, but isn't required to. — Peter Cordes, Jul 01 '20 at 20:57

score 5 · Answer 2 · edited May 23 '17 at 12:29

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.

Is it required that a C Variable Length Array is allocated from the stack?

2 Answers2

Linked