16

When VLAs were introduced in C 1999, I thought it was a great innovation to the language. However, having learned it was made optional in C 2011, I am wondering what led to its change in status, and if it means the feature is actually headed for obsolescence. If so, is there an equivalent notion of automatic management of dynamically sized data that is being considered to replace it?

I attempted to find the C 2011 rationale document, but it does not seem to be published yet.

Improve this question
2
  • Lack of adoption?
    – Ryan Reich
    Apr 5, 2016 at 19:39
  • @RyanReich: Probably, but why the resistance from the vendors?
    – jxh
    Apr 5, 2016 at 20:25

2 Answers 2

Reset to default
9

I've heard legends varying from "it should be optional as some small compilers should be able to be C11-compliant without VLAs" to "it was a mistake on the first place". I've never got one true and definite answer to this, though. Ultimately, I don't believe anyone really has one as the reason (assuming - and hoping - there is one) was never disclosed (as far as my old searches went).

From Chapter 4 (page 13) of Rationale for International Standard - Programming Languages - C 5.10 (2003)

By defining conforming implementations in terms of the programs they accept, the Standard leaves open the door for a broad class of extensions as part of a conforming implementation. By defining both conforming hosted and conforming freestanding implementations, the Standard recognizes the use of C to write such programs as operating systems and ROM-based applications, as well as more conventional hosted applications. Beyond this two-level scheme, no additional subsetting is defined for C, since the C89 Committee felt strongly that too many levels dilutes the effectiveness of a standard.

Emphasis mine. Notice that this decision goes against their own rationale. Yet, another thing made optional. Now you either get __STDC_NO_VLA__ or VLA support. It is a very odd decision.

Improve this answer
4
  • @jxh Didn't even see that. Thanks for pointing it out, it has been changed to a clearer and less ambiguous wording. I've seen motif as a synonym of motive and goal in some contexts, but I believe it is only common in artistic scenarios.
    – Bernardo Sulzbach
    Apr 5, 2016 at 23:51
  • The problem with having only a two-level scheme is that there are many useful features and guarantees which are widely but not quite universally supported, and which may allow some kinds of programs to be written much more efficiently than would otherwise be possible. The lack of any standard means of testing for the availability of such features makes it necessary for a significant fraction if not a majority of practical programs in many fields to make use of guarantees beyond those included in the Standard, and makes it difficult to determine with certainty whether any particular...
    – supercat
    Apr 21, 2016 at 19:31
  • ...program will work with any particular implementation. Defining a larger variety of optional features and guarantees which implementations can either support or refuse (by rejecting compilation) would make it possible to have a nice easy standard way of testing whether a program which properly specifies its requirements will work correctly on a platform: try to build it. If it builds, it will work. If not, it obviously won't. Increasing the fraction of programs for which it would be possible to guarantee that a successful build would guarantee successful operation...
    – supercat
    Apr 21, 2016 at 19:34
  • ...would seem far more valuable than merely maximizing the number of compilers that can handle the tiny fraction of programs that wouldn't benefit from features and guarantees beyond what the Standard requires.
    – supercat
    Apr 21, 2016 at 19:35
7

As far as I can determine from the public committee documents (in particular N1395), one of the major reasons for making VLA's (along with complex arithmetic and threading) optional was to make it possible to create conforming C compilers for small embedded processors.

The trend was that the compiler vendors that target embedded systems were staying on the C90 standard, because of the introduction of those large features that their customers weren't asking for.

Improve this answer
23
  • 1
    @JerryCoffin: Yes, but the code is only generated when sizeof() is actually used on the array. The compiler needs to track the info so it can generate the correct code, but that info need not be embedded into the in memory representation of the VLA.
    – jxh
    Apr 6, 2016 at 18:06
  • 2
    @jxh: As originally envisioned, freestanding and hosted implementations used the same core language. The differences were restricted to the library. In the case of VLAs, there's a difference in the language itself that (at least some vendors felt) wasn't really suitable to smaller embedded systems. As far as embedding the size goes: no, it's probably never absolutely necessary, but may be the easiest way (e.g., a few bytes of storage for the size might avoid many bytes of code to compute it).
    – Jerry Coffin
    Apr 6, 2016 at 18:10
  • 1
    @supercat: I can see the logic of cherry picking C library functionality, but making language features "optional" seems decidedly unhelpful to someone trying to write multi-platform C code. It used to be that C was the obvious choice for close to metal systems programming that could easily be retargeted to a different compiler and different hardware platform. Now, it is not so obvious.
    – jxh
    Apr 21, 2016 at 19:46
  • 1
    @jxh: C99 erred in adding mandatory features for which there was no demonstrated demand, and for which adding support would in some cases not be cheap [for some compilers, adding support for complex numbers might require a major reworking of the type-system code, especially if they use tricky bit codings for primitive types and such encodings don't have room for more choices]. A better route to take would be to start by making features optional and then seeing which ones end up getting used. If the Standard defines an optional feature before compiler vendors start providing...
    – supercat
    Apr 21, 2016 at 20:59
  • 2
    @supercat: Bombing the stack is not unique to VLA. Abnormally large automatic objects or an unrestrained function call stack will have similar issues. If the standard defines a means to detect failure for those cases, it would likely work for VLA as well. In terms of optional, it just makes it harder to argue for using new C features in new C code in new projects that are required to work on multiple platforms using compilers from multiple vendors.
    – jxh
    Apr 21, 2016 at 23:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.