4 ms·

Thanks for the link. As I understood it, it's just the support for the syntax that is mandatory. > Variable length arrays with automatic storage duration are a

Thanks for the link. As I understood it, it's just the support for the syntax that is mandatory. > Variable length arrays with automatic storage duration are a conditional feature that implementations need not support

LegionMammal978 3y ago
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 3y ago
  How do you create a variable array on the heap? confused
  - klodolph 3y ago
    With `malloc`, and converting the pointer to the correct type. void function(int n) { int (*arr)[n] = malloc(sizeof(*arr)); }
    - actionfromafar 3y ago
      wow, that's wild
      - uecker 3y ago
        That is exactly how you create any other type of object on the heap.
        actionfromafar 3y ago
        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 3y ago
        > 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.
        pjmlp 3y ago
        It only works at the same level, the moment they get passed in as arguments, they decay into pointers even if using [].
        LegionMammal978 3y ago
        I think there is a real difference: in the static case, the compiler can just recurse into the type definition at any point, compute fully-baked sizes and offsets, and cache them for the rest of the compilation. But in the dynamic case, you end up with the novel dataflow of types that depend on runtime values, and more machinery is necessary to track those dependencies. Of course, this runtime tracking has always been necessary for C99 VLA support, but I can easily see how it would be surprising for someone not deeply familiar with VLAs, especially given how the naive mental model of "T array[n]; is just syntax sugar for T *array = alloca(n * sizeof(T));" is sufficient for almost all of their uses in existing code. (In any case, it's obviously not "creating an object on the heap" that's the unusual part here!)

LegionMammal978 3y ago

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 3y ago
How do you create a variable array on the heap? confused
- klodolph 3y ago
  With `malloc`, and converting the pointer to the correct type. void function(int n) { int (*arr)[n] = malloc(sizeof(*arr)); }
  - actionfromafar 3y ago
    wow, that's wild
    - uecker 3y ago
      That is exactly how you create any other type of object on the heap.
      - actionfromafar 3y ago
        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 3y ago
        > 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.
        pjmlp 3y ago
        It only works at the same level, the moment they get passed in as arguments, they decay into pointers even if using [].
        LegionMammal978 3y ago
        I think there is a real difference: in the static case, the compiler can just recurse into the type definition at any point, compute fully-baked sizes and offsets, and cache them for the rest of the compilation. But in the dynamic case, you end up with the novel dataflow of types that depend on runtime values, and more machinery is necessary to track those dependencies. Of course, this runtime tracking has always been necessary for C99 VLA support, but I can easily see how it would be surprising for someone not deeply familiar with VLAs, especially given how the naive mental model of "T array[n]; is just syntax sugar for T *array = alloca(n * sizeof(T));" is sufficient for almost all of their uses in existing code. (In any case, it's obviously not "creating an object on the heap" that's the unusual part here!)