Comments on: C99′s VLAs are evil

By: Clark Cox on VLAs | Clark Cox on VLAs iphone | Clark Cox on VLAs iphone 4 | Iphone Mobile Phones > Iphone 4 Prices > Iphone Phones

Sat, 07 Aug 2010 01:58:09 +0000

[...] III, a Cocoa developer and fairly frequent contributor to the cocoa-dev mailing list, points out a major flaw in C99’s variable length arrays (VLAs) on his blog today. While it is nice to be able to allocate arrays on the stack, I’m with Clark on this one: use [...]

By: Rohar

Rohar — Wed, 04 Aug 2010 02:49:45 +0000

Compilers like gcc is happy even if you pass -1 to a variable-length array. In this case, sizeof(array) is 0xFFFFFFFC.

By: cyberscorpio

cyberscorpio — Fri, 26 Feb 2010 02:11:14 +0000

And the code can be wrapped in macro to simplify the works :)

#define GET_BUFFER(size) ….
#define FREE_BUFFER(…)

By: cyberscorpio

cyberscorpio — Fri, 26 Feb 2010 02:07:34 +0000

How about to do so:

void foo(int size) {
int asize = size;
if (asize > 1024)
asize = 1;
int buffer[asize];
int *array = buffer;
if (asize != size)
array = malloc(size * sizeof *array);

if(!array) {
//Error out here
return;
}

for(int i=0; i array[i] = i;
}
…

if (array != buffer)
free(array);
}

By: NoN@me

NoN@me — Sat, 10 Oct 2009 14:27:46 +0000

All normal compilers do stack allocations correctly, not by simply decrementing the stack pointer. For example (gcc (GCC) 3.4.2 (mingw-special)):
.00401730: 51 push ecx
.00401731: 89E1 mov ecx,esp
.00401733: 83C108 add ecx,008 ;”◘”
.00401736: 3D00100000 cmp eax,000001000 ;” ► ”
.0040173B: 7210 jb .00040174D —–↓ (1)
.0040173D: 81E900100000 sub ecx,000001000 ;” ► ”
.00401743: 830900 or d,[ecx],000 ;” ”
.00401746: 2D00100000 sub eax,000001000 ;” ► ”
.0040174B: EBE9 jmps .000401736 —–↑ (2)
.0040174D: 29C1 sub ecx,eax
.0040174F: 830900 or d,[ecx],000 ;” ”
.00401752: 89E0 mov eax,esp
.00401754: 89CC mov esp,ecx
.00401756: 8B08 mov ecx,[eax]
.00401758: 8B4004 mov eax,[eax][04]
.0040175B: FFE0 jmp eax

By: MRG

MRG — Thu, 09 Jul 2009 05:24:33 +0000

I disagree about the VLA having very little benefit. For numerical programming with a lot of matrices VLA’s can result in much cleaner code. The lack of VLA’s in pre C99 is one reason C was never widely used for numerical programming.

By: MRG

MRG — Thu, 09 Jul 2009 05:24:14 +0000

Sure, that’s right, passing the VLA to the function will not lead to a stack overflow.

Here is another example of allocating a VLA with malloc that is sometimes useful

void func(int m, int n) {

int i, j;
double (*data)[n];

data = malloc(m * n * sizeof(double));

for (i = 0; i < m; ++i) {
for (j = 0; j < n; ++j) {
data[i][j] = 0.;
}
}

/* do more stuff with data here */

free((void *) data);
}

By: Clark Cox

Clark Cox — Sat, 04 Jul 2009 22:30:14 +0000

The case of using the VLA in the function parameter is a different issue. It won’t lead to the same kind of stack corruption, as you aren’t allocating that array on the stack, you’re merely receiving a pointer to it. In that case, you’re free to validate the value of (n) before using the array; you don’t have that option for arrays with automatic storage.

The way C handles arrays and pointers in general is simultaneously one of its greatest strengths and one of its greatest weaknesses. VLA’s serve to obfuscate the issue, with very little benefit, and make it even easier to crash your program.

By: GRM

GRM — Sat, 04 Jul 2009 21:36:53 +0000

I agree with SNF. This is not a new problem at all. One should not allocate large work arrays in functions in this way. They should allocate them dynamically. If one does not want to worry about calling free() for every malloc() they can use alloca().

C99 VLA does have a benefit for multi dimensional arrays. For example:

void func(int n, double data[][n]) {
…
}

This cannot be done in C unless the number of columns is static. This can have huge benefits in scientific programming when pointer arrays cannot be used effectively.

By: SNF

SNF — Thu, 07 May 2009 14:48:57 +0000

You know, this really isn’t a new problem; it applies to compile-time-constant-length stack arrays as well. How do you know there’s room on the stack to allocate, say, int[1024]? You don’t.

You *assume* the runtime has allocated enough room for the stack, and that your function isn’t being called at a point when the stack has grown to the point where your array doesn’t fit.

The solution is the same in both cases: Use the stack responsibly. Don’t use it to store enormous arrays, and only use VLAs when the length is being passed or calculated from trusted data. Also, assert() is your friend.