4 ms·

> It's available in GCC and Clang, and we hope will be added to the C spec one day. This is widely used by open source software, eg. in systemd. It’s odd that

> It's available in GCC and Clang, and we hope will be added to the C spec one day. This is widely used by open source software, eg. in systemd. It’s odd that the suggestion for a feature lacking in C is to use a non standard but well used supported path. c’s main selling point (IMO) is that it _is_ a standard, and relying on compiler vendor extensions kind of defeats the purpose of that.

milesrout 2y ago
C's main selling point is not standardisation. It was widely used before standardisation and only standardised because it was useful.
rwmj 2y ago
It's so widely used by OS software that you're likely using already, that it's unlikely to be removed and much more likely to be standardized. This is in fact how standardization ought to work - standardize the proven best practices.
- maccard 2y ago
  I agree. But if we follow that logic then any compiler specific feature of either or clang is fair game, even if it’s not standard. MSVC doesn’t support it when compiling in C mode, for example.
  - lelanthran 2y ago
    > But if we follow that logic then any compiler specific feature of either or clang is fair game, even if it’s not standard. Well, yeah... How do you think Annex K got in?
dietr1ch 2y ago
> 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
flohofwoe 2y ago
Standard C is only the least common denominator that compiler vendors agreed on, and the C standard committee works 'reactively' by mostly standardizing features that have been in common use as non-standard extensions - sometimes for decades before standardization happens (this is probably the main difference to the C++ committee). The *actual* power and flexibility of C lies in the non-standard, vendor-specific language extensions.
shakna 2y ago
Defer was almost part of the C23 standard, but didn't quite make it. They've slimmed and changed a few things, and it looks like it very much might be part of the next. [0] https://thephd.dev/c2y-the-defer-technical-specification-its-time-go-go-go https://thephd.dev/c2y-the-defer-technical-specification-its... [1] https://thephd.dev/_vendor/future_cxx/technical%20specification/C%20-%20defer/C%20-%20defer%20Technical%20Specification.pdf https://thephd.dev/_vendor/future_cxx/technical%20specificat...

milesrout 2y ago

C's main selling point is not standardisation. It was widely used before standardisation and only standardised because it was useful.

rwmj 2y ago

It's so widely used by OS software that you're likely using already, that it's unlikely to be removed and much more likely to be standardized. This is in fact how standardization ought to work - standardize the proven best practices.

maccard 2y ago
I agree. But if we follow that logic then any compiler specific feature of either or clang is fair game, even if it’s not standard. MSVC doesn’t support it when compiling in C mode, for example.
- lelanthran 2y ago
  > But if we follow that logic then any compiler specific feature of either or clang is fair game, even if it’s not standard. Well, yeah... How do you think Annex K got in?

dietr1ch 2y ago

> 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

flohofwoe 2y ago

Standard C is only the least common denominator that compiler vendors agreed on, and the C standard committee works 'reactively' by mostly standardizing features that have been in common use as non-standard extensions - sometimes for decades before standardization happens (this is probably the main difference to the C++ committee). The *actual* power and flexibility of C lies in the non-standard, vendor-specific language extensions.

shakna 2y ago

Defer was almost part of the C23 standard, but didn't quite make it. They've slimmed and changed a few things, and it looks like it very much might be part of the next. [0] https://thephd.dev/c2y-the-defer-technical-specification-its-time-go-go-go https://thephd.dev/c2y-the-defer-technical-specification-its... [1] https://thephd.dev/_vendor/future_cxx/technical%20specification/C%20-%20defer/C%20-%20defer%20Technical%20Specification.pdf https://thephd.dev/_vendor/future_cxx/technical%20specificat...