5 ms·

> relying on compiler vendor extensions kind of defeats the purpose of that. Let's be honest, how many compilers are available, and how many of those would yo

> relying on compiler vendor extensions kind of defeats the purpose of that. Let's be honest, how many compilers are available, and how many of those would you actually use? The answer isn't more than 4 and the 2 compilers you are most likely to use among those already support this and probably won't stop supporting without a good alternative. I like standardisation, but you have to be realistic when it helps you without a large real cost other than fighting your ideals for getting this into the standard first.

DanielHB 2y ago
There are quite a lot of embedded code that relies on obscure C compilers created and maintained by the CPU manufacturer. But then again you are probably not doing a whole lot of heap management in embedded code.
- dietr1ch 2y ago
  That sounds like the kind of code that you want to be done with and never touch again. You can only dream of it not being buggy or catching up with the newest standard.
  - DanielHB 2y ago
    No it is more like the 10000 lines of code running in your washing machine, you will probably be updating it in the next year revision of the product. It is quite common for this code to have all variables be global and just not have any heap allocations at all. Sometimes you don't even have variables in the stack either (besides the globals).
    - hn_acc1 2y ago
      I much prefer the purely-mechanical washing machines for this reason.. Way less to go wrong..
      - DanielHB 2y ago
        It is not that bad, the code is easier than your average web server and it is usually only one CPU for consumer devices. It gets bad if: 1) You add embedded linux 2) You have multiple CPUs that need to communicate with each other. 3) Both of the above (then the complexity skyrockets) (this happens in modern cars) So basically if it has a full LCD display (instead of 7-segment with a few extra toggle lights) I don't buy it. It is actually quite refreshing code to read and write, yes the quality is often bad, but it often feels like school projects where they are small enough you can hold the complete system in your head. And it usually doesn't integrate with anything else besides the eletronics in the board
  - TickleSteve 2y ago
    static allocation is the recommended mechanism in embedded code for reliability reasons, you have thought about you worst-case allocation and accounted for it... right? Also fragmentation and dynamic behaviour are bad things when your code has to run "forever".
amjoshuamichael 2y ago
For me, the point of writing something in C is portability. There were C compilers 30 years ago, there are C compilers now, and there will almost certainly be C compilers 30 years from now. If I want to write a good, portable library that's going to be useful for a long time, I'll do it in C. This is, at least, the standard in many gamedev circles (see: libsdl, libfreetype, the stb_* libraries). Under that expectation, I write to a standard, not a compiler.
- rwmj 2y ago
  The bad news is that C23 broke a lot of existing code[1]. We had to do a lot of work in Fedora to fix the resulting mess. [1] https://gcc.gnu.org/gcc-15/porting_to.html#c23 https://gcc.gnu.org/gcc-15/porting_to.html#c23
  - fuhsnn 2y ago
    For the cases in linked doc, does adding -std=gnu17 to packages not suffice? I would consider the union initializer change (require adding -fzero-init-padding-bits=unions for old behavior) much more hidden and dangerous, which is not directly related to ISO C23 standard.
    - rwmj 2y ago
      It's true that it does, yes. However that would still require changes to the build system. In any case for the vast majority of the packages we decided to fix (if you think this is a fix!) the code.
      - fuhsnn 2y ago
        >if you think this is a fix I would count it as doing maintenance work for the upstream, kudos for doing this!
  - ForTheKidz 2y ago
    > Note that the bool type is not the same as int at ABI level, Huh. Wonder what the benefits of that are. Bools being ints never struck me as a serious problem. I wonder if this catches people who accidentally assign rather than compare tho....
maccard 2y ago
If this is the argument then the actual standardisation is useless. I primarily use windows so I’m affected by one of the major compilers that doesn’t support this feature. This is no different to saying “chrome supports feature X, and realistically has y% market share so don’t let the fact that other browsers exist get in the way”. Call it a posix extension, fair enough. But if your reason for writing C is that it’s portable, don’t go relying on non portable vendor specific extensions.
- dietr1ch 2y ago
  It's not, and even if there's something in the standard, your compiler of choice might not support it yet. It's the same thing with the web and browser vendors, there's a constant mismatch, browsers propose and implement things and they may get standardized, and the standard dictates new requirements which might get implemented by all vendors. The point of standardisation is defining behaviour for the things that are implemented as exploratory improvements and should be implemented on the more conservative compilers. It's your choice whether to target the standard or a few selected compilers, there's a cost for both options between being late to improvements vs the possibility of needing to revisit your code around each of the "extensions" you decided to depend on. If in certain projects portability is somehow of upmost importance, then any discussion around looking through the standard's black box to reach out for new stuff is kind of useless.
deleted 2y ago
[deleted]

DanielHB 2y ago

There are quite a lot of embedded code that relies on obscure C compilers created and maintained by the CPU manufacturer. But then again you are probably not doing a whole lot of heap management in embedded code.

dietr1ch 2y ago
That sounds like the kind of code that you want to be done with and never touch again. You can only dream of it not being buggy or catching up with the newest standard.
- DanielHB 2y ago
  No it is more like the 10000 lines of code running in your washing machine, you will probably be updating it in the next year revision of the product. It is quite common for this code to have all variables be global and just not have any heap allocations at all. Sometimes you don't even have variables in the stack either (besides the globals).
  - hn_acc1 2y ago
    I much prefer the purely-mechanical washing machines for this reason.. Way less to go wrong..
    - DanielHB 2y ago
      It is not that bad, the code is easier than your average web server and it is usually only one CPU for consumer devices. It gets bad if: 1) You add embedded linux 2) You have multiple CPUs that need to communicate with each other. 3) Both of the above (then the complexity skyrockets) (this happens in modern cars) So basically if it has a full LCD display (instead of 7-segment with a few extra toggle lights) I don't buy it. It is actually quite refreshing code to read and write, yes the quality is often bad, but it often feels like school projects where they are small enough you can hold the complete system in your head. And it usually doesn't integrate with anything else besides the eletronics in the board
- TickleSteve 2y ago
  static allocation is the recommended mechanism in embedded code for reliability reasons, you have thought about you worst-case allocation and accounted for it... right? Also fragmentation and dynamic behaviour are bad things when your code has to run "forever".

amjoshuamichael 2y ago

For me, the point of writing something in C is portability. There were C compilers 30 years ago, there are C compilers now, and there will almost certainly be C compilers 30 years from now. If I want to write a good, portable library that's going to be useful for a long time, I'll do it in C. This is, at least, the standard in many gamedev circles (see: libsdl, libfreetype, the stb_* libraries). Under that expectation, I write to a standard, not a compiler.

rwmj 2y ago
The bad news is that C23 broke a lot of existing code[1]. We had to do a lot of work in Fedora to fix the resulting mess. [1] https://gcc.gnu.org/gcc-15/porting_to.html#c23 https://gcc.gnu.org/gcc-15/porting_to.html#c23
- fuhsnn 2y ago
  For the cases in linked doc, does adding -std=gnu17 to packages not suffice? I would consider the union initializer change (require adding -fzero-init-padding-bits=unions for old behavior) much more hidden and dangerous, which is not directly related to ISO C23 standard.
  - rwmj 2y ago
    It's true that it does, yes. However that would still require changes to the build system. In any case for the vast majority of the packages we decided to fix (if you think this is a fix!) the code.
    - fuhsnn 2y ago
      >if you think this is a fix I would count it as doing maintenance work for the upstream, kudos for doing this!
- ForTheKidz 2y ago
  > Note that the bool type is not the same as int at ABI level, Huh. Wonder what the benefits of that are. Bools being ints never struck me as a serious problem. I wonder if this catches people who accidentally assign rather than compare tho....

maccard 2y ago

If this is the argument then the actual standardisation is useless. I primarily use windows so I’m affected by one of the major compilers that doesn’t support this feature. This is no different to saying “chrome supports feature X, and realistically has y% market share so don’t let the fact that other browsers exist get in the way”. Call it a posix extension, fair enough. But if your reason for writing C is that it’s portable, don’t go relying on non portable vendor specific extensions.

dietr1ch 2y ago
It's not, and even if there's something in the standard, your compiler of choice might not support it yet. It's the same thing with the web and browser vendors, there's a constant mismatch, browsers propose and implement things and they may get standardized, and the standard dictates new requirements which might get implemented by all vendors. The point of standardisation is defining behaviour for the things that are implemented as exploratory improvements and should be implemented on the more conservative compilers. It's your choice whether to target the standard or a few selected compilers, there's a cost for both options between being late to improvements vs the possibility of needing to revisit your code around each of the "extensions" you decided to depend on. If in certain projects portability is somehow of upmost importance, then any discussion around looking through the standard's black box to reach out for new stuff is kind of useless.

deleted 2y ago

[deleted]