5 ms·

I like how delightfully stable GCC and C is when things from C99 is mandatory only now, a quarter of a century later.

by actionfromafar 3y ago

haolez 3y ago
Didn't some parts of C99 get rolled back on C11 and other newer ones?
- fl0ki 3y ago
  Variable Length Arrays were mandatory in C99, optional in C11, and are mandatory again in C23. I'm curious how these dynamics play out in less popular compilers. If a compiler implemented VLAs in C99, they almost certainly still have that feature for backwards compatibility even after they support C11. Is there any compiler which appeared on the scene between C11 and C23, and during that window, chose not to support VLAs and thus C99? It's not like C11 itself was very widely adopted, precisely because of the long implementation and industry rollout windows.
  - Joker_vD 3y ago
    Uh, are they mandatory again? For these reasons, we propose to make variably-modified types mandatory in C23. VLAs with automatic storage duration remain an optional language feature due to their higher implementation overhead and security concerns on some implementations (i.e. when allocated on the stack and not using stack probing). from N2778 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf)
    - fractalb 3y ago
      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.
    - fl0ki 3y ago
      I'm not tuned in to the nuances here but I note that whoever felt they understood it well enough to update Wikipedia summarized this as "The C23 standard makes VLA types mandatory again. Only creation of VLA objects with automatic storage duration is optional." https://en.wikipedia.org/wiki/Variable-length_array#C99 https://en.wikipedia.org/wiki/Variable-length_array#C99 If that phrasing isn't accurate I'm sure they'd appreciate an edit.
  - fractalb 3y ago
    VLA support is mandatory in C23? I'd like to know the rationale behind this decision. Can you provide any references? Thanks.
    - veltas 3y ago
      If I understand right, this is mandatory: void example(int n) { printf("%zu", sizeof(int[n])); } void example2(int n, int (*a)[n]) { } This is optional: void example3(int n) { int x[n]; }
  - garaetjjte 3y ago
    Portable code couldn't use VLAs anyway, it was never supported in MSVC.
    - pjmlp 3y ago
      Among others.
    - uecker 3y ago
      Portable C code could not use MSVC until recently, because MSVC was stuck with C89 because MS wanted everybody to switch to C++.
  - uecker 3y ago
    VLAs were optional in C11 and compilers that supported them in C99 also supported them in C11. The only important compiler not supporting VLAs is MSVC, but this compiler also did not support other features from C99. People using MSVC were stuck using an obsolete version of C for a long time. Recently this changed and MSVC started to support C11 and C17 - skipping C99.
fl0ki 3y ago
And still not even mandatory if you use -fpermissive or -std=c89. I don't envy how much tech debt they have to deal with, while still trying to make it possible for new code to have a more modern experience. For all the excitement around new languages, we're still going to have a lot of C code for a long time, and difficult work like this should be appreciated.
estebank 3y ago
I can't help but wonder how many bugs could have been detected and fixed a quarter of a century earlier if those lints had been adopted more diligently by the C ecosystem.
- loeg 3y ago
  My perception is that more and better warnings, and common use of -Wall, came into vogue around the time of GCC 4, in the mid 2000s. It would have been pretty abrupt to immediately enforce C99 in 1999-2000.
  - estebank 3y ago
    Yet in 2022 this change from warn by default to error by default was consequential enough for Fedora: >> So what is the current status? How many packages are going to be affected by this change? How are we going to track the progress? > I see an unaudited rebuild failure rate of about 10% for rebuilds of source packages that produce arch-full binary packages. This number does not include packages which fail to build in rawhide without the compiler change. It includes packages which configure checks for something that we really do not support (like setproctitle or strlcpy). After the first pass completes, I'll have to do a second pass with the expected-to-be-undeclared functions gathered from the first pass filtered out. That should give us better numbers.
    - loeg 3y ago
      If this was intended to be responsive to my comment, I'm missing the connection.
    - pm215 3y ago
      My impression is that a lot of the fallout was related to checks in configure scripts and equivalent. That kind of code was traditionally written a lot more sloppily and was much less likely to have the "standard" set of warnings or the make-warnings-into-errors flag enabled. So, yes, quite a lot of packages failed to build, but the offending code was typically not code that was run when somebody was actually using the program and not code where bugs were consequential. And of course Fedora's a big collection of software with a pretty long tail -- 10% of packages likely works out to a lot less than 10% of user-executing-a-program hours.
spookie 3y ago
The other day I tried to compile a really old program, the Power Crust and its predecessor. It just worked, for some reason I was expecting it not to. I didn't even have the filetype it was supposed to accept, but it was fine, it was just a list of points. One per line. Sanity is such a rare thing these days.
lelanthran 3y ago
> I like how delightfully stable GCC and C is when things from C99 is mandatory only now, a quarter of a century later. This is how stable it is - they were still supporting C constructs from prior to C89 standardisation (which is when, I believe, void pointers were introduced). "maybe consider using void * in more places (particularly for old programs that predate the introduction of void * into the C language). "

I like how delightfully stable GCC and C is when things from C99 is mandatory only now, a quarter of a century later.

haolez 3y ago

Didn't some parts of C99 get rolled back on C11 and other newer ones?

fl0ki 3y ago
Variable Length Arrays were mandatory in C99, optional in C11, and are mandatory again in C23. I'm curious how these dynamics play out in less popular compilers. If a compiler implemented VLAs in C99, they almost certainly still have that feature for backwards compatibility even after they support C11. Is there any compiler which appeared on the scene between C11 and C23, and during that window, chose not to support VLAs and thus C99? It's not like C11 itself was very widely adopted, precisely because of the long implementation and industry rollout windows.
- Joker_vD 3y ago
  Uh, are they mandatory again? For these reasons, we propose to make variably-modified types mandatory in C23. VLAs with automatic storage duration remain an optional language feature due to their higher implementation overhead and security concerns on some implementations (i.e. when allocated on the stack and not using stack probing). from N2778 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf)
  - fractalb 3y ago
    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.
  - fl0ki 3y ago
    I'm not tuned in to the nuances here but I note that whoever felt they understood it well enough to update Wikipedia summarized this as "The C23 standard makes VLA types mandatory again. Only creation of VLA objects with automatic storage duration is optional." https://en.wikipedia.org/wiki/Variable-length_array#C99 https://en.wikipedia.org/wiki/Variable-length_array#C99 If that phrasing isn't accurate I'm sure they'd appreciate an edit.
- fractalb 3y ago
  VLA support is mandatory in C23? I'd like to know the rationale behind this decision. Can you provide any references? Thanks.
  - veltas 3y ago
    If I understand right, this is mandatory: void example(int n) { printf("%zu", sizeof(int[n])); } void example2(int n, int (*a)[n]) { } This is optional: void example3(int n) { int x[n]; }
- garaetjjte 3y ago
  Portable code couldn't use VLAs anyway, it was never supported in MSVC.
  - pjmlp 3y ago
    Among others.
  - uecker 3y ago
    Portable C code could not use MSVC until recently, because MSVC was stuck with C89 because MS wanted everybody to switch to C++.
- uecker 3y ago
  VLAs were optional in C11 and compilers that supported them in C99 also supported them in C11. The only important compiler not supporting VLAs is MSVC, but this compiler also did not support other features from C99. People using MSVC were stuck using an obsolete version of C for a long time. Recently this changed and MSVC started to support C11 and C17 - skipping C99.

fl0ki 3y ago

And still not even mandatory if you use -fpermissive or -std=c89. I don't envy how much tech debt they have to deal with, while still trying to make it possible for new code to have a more modern experience. For all the excitement around new languages, we're still going to have a lot of C code for a long time, and difficult work like this should be appreciated.

estebank 3y ago

I can't help but wonder how many bugs could have been detected and fixed a quarter of a century earlier if those lints had been adopted more diligently by the C ecosystem.

loeg 3y ago
My perception is that more and better warnings, and common use of -Wall, came into vogue around the time of GCC 4, in the mid 2000s. It would have been pretty abrupt to immediately enforce C99 in 1999-2000.
- estebank 3y ago
  Yet in 2022 this change from warn by default to error by default was consequential enough for Fedora: >> So what is the current status? How many packages are going to be affected by this change? How are we going to track the progress? > I see an unaudited rebuild failure rate of about 10% for rebuilds of source packages that produce arch-full binary packages. This number does not include packages which fail to build in rawhide without the compiler change. It includes packages which configure checks for something that we really do not support (like setproctitle or strlcpy). After the first pass completes, I'll have to do a second pass with the expected-to-be-undeclared functions gathered from the first pass filtered out. That should give us better numbers.
  - loeg 3y ago
    If this was intended to be responsive to my comment, I'm missing the connection.
  - pm215 3y ago
    My impression is that a lot of the fallout was related to checks in configure scripts and equivalent. That kind of code was traditionally written a lot more sloppily and was much less likely to have the "standard" set of warnings or the make-warnings-into-errors flag enabled. So, yes, quite a lot of packages failed to build, but the offending code was typically not code that was run when somebody was actually using the program and not code where bugs were consequential. And of course Fedora's a big collection of software with a pretty long tail -- 10% of packages likely works out to a lot less than 10% of user-executing-a-program hours.

spookie 3y ago

The other day I tried to compile a really old program, the Power Crust and its predecessor. It just worked, for some reason I was expecting it not to. I didn't even have the filetype it was supposed to accept, but it was fine, it was just a list of points. One per line. Sanity is such a rare thing these days.

lelanthran 3y ago

> I like how delightfully stable GCC and C is when things from C99 is mandatory only now, a quarter of a century later. This is how stable it is - they were still supporting C constructs from prior to C89 standardisation (which is when, I believe, void pointers were introduced). "maybe consider using void * in more places (particularly for old programs that predate the introduction of void * into the C language). "