What technical flaws do VLAs have in the style of C99?

Question

I heard from many people that the variable-length array introduced on C99 is terrible. Some IRC guys said a minute ago, "I don’t think C ++ will get a VLA, strousoup made very negative reviews about them."

What are the reasons these people hate VLA?

Answer 1

VLAs allocate arrays on the stack at runtime, which makes it more difficult or impossible to determine the stack size used at compile time. Since the stack has a fairly small amount of available memory (compared to a bunch), many fear that VLAs have great potential for.

The upcoming version of the MISRA-C coding standard is likely to also prohibit VLA.

Answer 2

Although variable-length arrays have their problems, you should keep in mind how they became: as a replacement for alloca() , which is perhaps even more problematic .

Although the PDP-11 was trivial, this was not the case on other architectures, and Ritchie and Thompson removed it from their implementation .

However, variable-sized automatic distribution was apparently useful enough that alloca() received a resurrection despite its problems (in particular, it cannot be used wherever arbitrary function calls are possible, and on many architectures it should be a compiler built in anyway). Working Group C agreed to provide such a function, but analyzes variable-length arrays in an excellent solution.

If you look at the functions added using C99 (complex numbers, type math, restrict , ...), you should notice that many of them are aimed at making C the best language for numerical calculations. Variable-length arrays are also useful, and I suppose Fortran already had them at the time. In addition, their implementation also led to modified derived types (for example, pointers to variable-sized arrays), which are especially useful when working with matrices.

Answer 3

VLAs greatly facilitate stack overflow. In most places where you would use a VLA, you would have to base the length on one of the function parameters. If the parameter is what you are not expecting, you can end up allocating a very large array on the stack. If you cannot be sure that no combination of arguments can cause a stack overflow, you should use dynamic allocation.

One place that it might make sense to use them is embedded platforms, because when doing embedded programming, this is one of the few situations where you will probably be careful enough to monitor your memory usage to make sure you won’t have a stack overflow .

Answer 4

As others have pointed out, VLAs simplify stack overflows. I am not a compiler writer, but I understand that VLA can also be a fake for support (now they become optional in C2011). And their use is limited to the area of ​​blocks or functions; you cannot use VLAs in the file area, and they cannot have external binding.

I would not want the VLA syntax to go away though; this is very convenient for the dynamic distribution of multidimensional arrays, where the internal dimensions are unknown until runtime, for example:

 size_t r, c; // get values for r and c int (*arr)[c] = malloc(r * sizeof *arr); if (arr) { ... arr[i][j] = ...; ... free(arr); } 

One contiguous distribution (and one corresponding free ), and I can fine-tune it as a 2D array. Alternatives usually mean splitting in parts:

 size_t r, c; ... int **arr = malloc(sizeof *arr * r); if (arr) { for (i = 0; i < c; i++) arr[i] = malloc(sizeof *arr[i] * c); ... arr[i][j] = ...; ... for (i = 0; i < c; i++) free(arr[i]); free(arr); } 

or using 1-dimensional offsets:

 int *arr = malloc(sizeof *arr * r * c); if (arr) { ... arr[i * r + j] = ...; ... free(arr); }