Hacker News Reader

Comment by Retr0spectrum | Hacker News Reader

> written in C99 (without VLAs)

Can someone fill me in on why VLAs are a non-feature?

The most obvious reason is portability. Even though it's been nearly twenty years since the C99 standard, some compilers still haven't implemented VLAs. To make things worse, the next revision of the C standard (C11) made VLAs optional, so these compilers now have an excuse to never implement it.

But even discounting that, there are still some issues with VLAs. For instance, the Linux kernel decided to remove all uses of VLAs they had, because they generate worse code than a partially-used fixed-size buffer, and also make it easier to overflow the kernel stack. VLAs, like their ancestor alloca(), seem convenient but often are more trouble than they're worth.

They're universally regarded as a dangerous, difficult to use feature (yes, even by C programmers) and are no longer required in C11. VLAs can have nasty side effects like stack corruption and are a leaky abstraction at best. You can't expose a VLA's size through the ABI, for instance.

> You can't expose a VLA's size through the ABI, for instance.

Can you clarify what you mean by this? It's not clear to me what it would even mean to expose a VLA in the ABI: they are function scoped and as a result it doesn't seem like they could escape to the ABI.

GCC added an extension years back that allows VLAs as struct members and function arguments. Clang had the good sense not to, thankfully.

Can you provide a reference to both of those affecting _ABI_?

"VLAs as [...] function arguments" sounds like it would just be normal passing of arrays. It's not clear that VLAs have any effect here.

"VLAs as struct members [...]" is still not clearly an ABI issue: if they existed, the types would still be confined to the function they are declared in, and thus would not affect ABI.

Because MSVC does not support those, and VLA became optional in C11.

That's why we decided to not use them in dav1d.

Because VLA are considered a design mistake, which made C even more insecure, and as such have been made optional in C11.

Additionally gcc and clang are probably the only C compilers that ever bothered to support it.

pcc, tcc, and icc all appear to support variable length arrays.

It may be more accurate to state that "msvc is probably the only C compiler that didn't bother to support it"?

(Though it would be interesting to perform a more complete survey of C compilers to determine how widely supported VLAs are)

(For the uninformed like me, VLA stands for Variabe-Length Array)

One of the main issue is no error checking on this kind of "allocation" (it's the same as alloca()). This issue also somehow exists with a fixed size buffer, but at least you get a much more predictable outcome (you have full control on the stack usage, unless you have a user controlled recursion).

You can check for errors with alloca. It returns NULL on failure. You have the same problem as with error checking malloc. On platforms with overcommit (any fork-based UNIX, except maybe Solaris) it doesn't fail at allocation time, it fails when you try to access the memory and fail to map a page. But at least on 32-bit systems it can detect when you exhaust your address space (an actual problem for things like web browsers that still commonly ship 32-bit binaries and use lots and lots of threads).

But yeah, the real reason is that MSVC will never implement VLAs.

I worry you are mixing up alloca and malloc. Alloca allocates off the stack. All modern platforms have irritatingly small stack sizes, and if you overflow them your code just defaults with an annoyingly imprecise error. There is no overcommitting with stacks in practice.

It returns NULL to indicate errors? Not any platform I've used lately.

The Linux man page is in fact explicit that it never returns NULL:

  RETURN VALUE
       The alloca() function returns a pointer to the
       beginning of the allocated space.  If the
       allocation causes stack overflow, program behavior
       is undefined.

  NOTES
       ...
       The inlined code often consists of a single          
       instruction adjusting the stack pointer, and
       does not check for stack overflow.  Thus, there
       is no NULL error return.

As a practical matter it is difficult for an implementation to have alloca return an error value even if they wanted to: it would be both two slow and in some cases "impossible" to know ahead of time in the same way that malloc is unlikely to return null on some systems.

How could alloca return NULL? You would have to catch bumping into a guard page would you not?

_theoretically_ a C implementation could track the maximum stack size it has allocated, detect would be overflows, and report them.

guard pages are one mechanism for doing that.

> you have full control on the stack usage, unless you have a user controlled recursion

IMO, the reality with C is that one needs to be aware of input, whether using VLAs, recursion, or any number of other mechanisms (overflowing calculated values passed to malloc, etc).

It isn't clear that VLAs are a significant departure from what C already provides in the way of unsafety.

Very easy to blow up your stack with unsanitized input

Though that is true of a lot of elements of C.

Reply on news.ycombinator.com