8 ms·

> written in C99 (without VLAs) Can someone fill me in on why VLAs are a non-feature?

jbk 8y ago
Because MSVC does not support those, and VLA became optional in C11. That's why we decided to not use them in dav1d.
cesarb 8y ago
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.
gilnaa 8y ago
Very easy to blow up your stack with unsanitized input
- codys 8y ago
  Though that is true of a lot of elements of C.
AlotOfReading 8y ago
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.
- codys 8y ago
  > 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.
  - AlotOfReading 8y ago
    GCC added an extension years back that allows VLAs as struct members and function arguments. Clang had the good sense not to, thankfully.
    - codys 8y ago
      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.
ux 8y ago
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).
- derf_ 8y ago
  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.
  - CJefferson 8y ago
    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.
  - BeeOnRope 8y ago
    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.
pjmlp 8y ago
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.
- codys 8y ago
  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)
sedatk 8y ago
(For the uninformed like me, VLA stands for Variabe-Length Array)

jbk 8y ago

Because MSVC does not support those, and VLA became optional in C11. That's why we decided to not use them in dav1d.

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.

gilnaa 8y ago

Very easy to blow up your stack with unsanitized input

codys 8y ago
Though that is true of a lot of elements of C.

AlotOfReading 8y ago

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.

codys 8y ago
> 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.
- AlotOfReading 8y ago
  GCC added an extension years back that allows VLAs as struct members and function arguments. Clang had the good sense not to, thankfully.
  - codys 8y ago
    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.

ux 8y ago

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).

derf_ 8y ago
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.
- CJefferson 8y ago
  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.
- BeeOnRope 8y ago
  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.

pjmlp 8y ago

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.

codys 8y ago
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)

sedatk 8y ago

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