[LegionMammal978]

The syntax and also the semantics. For instance, you can take the sizeof() a variably-modified type, or the offsetof() one of its fields, and the compiler has to do all the layout calculations implied by the type declaration at runtime. These features are partially what motivated the mandatory support. The only part that is still optional is using such types by value as stack variables (i.e., variables with automatic storage duration).

[actionfromafar]

How do you create a variable array on the heap?

confused

[klodolph]

With `malloc`, and converting the pointer to the correct type.

    void function(int n) {
      int (*arr)[n] = malloc(sizeof(*arr));
    }

[actionfromafar]

wow, that's wild

[uecker]

That is exactly how you create any other type of object on the heap.

[actionfromafar]

Snarky or just know a lot? It changes quite a bit how the compiler works. It has to know to make sure malloc gets the array element size argument multiplied in runtime by n. To a mere user it broke my mental shorthand of how a C compiler works.

[Joker_vD]

> It has to know to make sure malloc gets the array element size argument multiplied in runtime by n

Um, C compilers already do that with arrays with compile-time lengths.

    #include <stdio.h>

    void main(void) {
        char x[20][30];
        printf("%zu\n%zu\n", sizeof(x), sizeof(x[0]));
    }

prints

    600
    30

so you can have "char *y = malloc(sizeof(x)); memcpy(y, x, sizeof(x));" and it must work since C89 at least. The main problem with VLAs is that they make exact the stack frame size unknown until runtime which complicates function prologues/epilogues but that's the problem in the codegen part of the backend, the semantics machinery is mostly in the place already.

P.S. And yes, uecker is a member of the ISO C WG14 and GCC contributor, according to his profile.