3 ms·

> I'm delighted this standard header is now a... standard! The POSIX standard isn't the C standard though (for better or worse). Especially on Windows with MS

> I'm delighted this standard header is now a... standard! The POSIX standard isn't the C standard though (for better or worse). Especially on Windows with MSVC "obvious" things like this are traditionally a royal PITA (which also means that a lot of C code coming from the UNIX world simply doesn't build on MSVC even though MSVC is now a decent standard-C compiler again). But yeah, the C standard is just the minimal common subset of what C compilers offer. The good stuff is all in Clang and GCC extensions.

derefr 3y ago
> But yeah, the C standard is just the minimal common subset of what C compilers offer. Why is this? Most other standards — for languages or otherwise — seem to run ahead of implementation, as meetings of major players agreeing on what they'll all implement next, with the standard constraining the implementations on how to do that. But the C standard is seemingly instead just an external, descriptivist report on "what you can get away with writing in C while keeping it completely portable."
- flohofwoe 3y ago
  Don't know, most likely reason is probably that the C standard was always an afterthought and 'reactive' in the C world (e.g. the language already existed for nearly two decades before the first standard was released). TBH I think the general idea of "let's only standardise what has already been implemented in real world extensions and proven its worth" isn't too bad, especially when looking at the mess that the C++ standard committee made of C++ in the last decade. But even with this pragmatic approach I imagine it's a highly political balancing act to get multiple powerful compiler vendors to actually agree on the same thing. See for instance the C23 auto proposal which contains a special exception for Clang's behaviour which clashes with GCC's behaviour: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm
  - buserror 3y ago
    Problem is, that approach forces the committee to roll in stuff from the C++ spec -- stuff that would have been shot in flame if you had hinted about that sort of things as a proposal C extension.. For example the [[keywords]] that had was rolled in because it was already out there -- imagine proposing that out of the blue and see a people self-propel into orbit... On other hand the Case A ... B: syntax that has been out there for 30+ years, well there's a proposal for it but it won't be THAT because well it hasn't been invented here really, we'll make up a different syntax for it instead...
    - sigsev_251 3y ago
      Well there is a reason for that. The A ... B syntax requires that you use spaces between A, the three dots and B, else it will be lexed as a single number. C is supposed to ignore whitespace, it wouldn't make sense to add a feature that requires whitespace.
      - buserror 3y ago
        It doesn't requires a space, you could modify the lexer to recognize '..' as a prefix and solve that problem, it's just a choice they made to refuse that it could be implemented by just having one character forward looking lexer. It is not because it is implemented like that in gcc (requiring a space, possibly so they didnt have to modify the lexer) that it ought to be specced like that.
        teo_zero 3y ago
        All C lexers are greedy, i.e. they extend the current token as far as they can. So "0..9" is split as a token "0." (numeric literal) followed by token "." (operator) followed by token "9" (numeric literal). To do what you suggest, the lexers would need a major redesign, not just a small change.
    - avar 3y ago
      C still supports EBCDIC, and other potential non-ASCII character sets one might invent in the future. It promises e.g. that 0..9 is contiguous, but e.g. "case 'A' ... 'Z'" would behave differently.
- quelsolaar 3y ago
  Im in the wg14 and this is not true. The later versions of the C standard are not dependable and diverges quite a bit from implementations. There are lots of things in the C standard text that you should not depend on. There are in fact extensions that are more commonly implemented than standard features, and some standard features that hav no known implementations. I hope to work on a guide for developers who want a “dependable-C” where they can guarantee it will compile and run correctly in as many implementations as possible.

derefr 3y ago

> But yeah, the C standard is just the minimal common subset of what C compilers offer. Why is this? Most other standards — for languages or otherwise — seem to run ahead of implementation, as meetings of major players agreeing on what they'll all implement next, with the standard constraining the implementations on how to do that. But the C standard is seemingly instead just an external, descriptivist report on "what you can get away with writing in C while keeping it completely portable."

flohofwoe 3y ago
Don't know, most likely reason is probably that the C standard was always an afterthought and 'reactive' in the C world (e.g. the language already existed for nearly two decades before the first standard was released). TBH I think the general idea of "let's only standardise what has already been implemented in real world extensions and proven its worth" isn't too bad, especially when looking at the mess that the C++ standard committee made of C++ in the last decade. But even with this pragmatic approach I imagine it's a highly political balancing act to get multiple powerful compiler vendors to actually agree on the same thing. See for instance the C23 auto proposal which contains a special exception for Clang's behaviour which clashes with GCC's behaviour: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm
- buserror 3y ago
  Problem is, that approach forces the committee to roll in stuff from the C++ spec -- stuff that would have been shot in flame if you had hinted about that sort of things as a proposal C extension.. For example the [[keywords]] that had was rolled in because it was already out there -- imagine proposing that out of the blue and see a people self-propel into orbit... On other hand the Case A ... B: syntax that has been out there for 30+ years, well there's a proposal for it but it won't be THAT because well it hasn't been invented here really, we'll make up a different syntax for it instead...
  - sigsev_251 3y ago
    Well there is a reason for that. The A ... B syntax requires that you use spaces between A, the three dots and B, else it will be lexed as a single number. C is supposed to ignore whitespace, it wouldn't make sense to add a feature that requires whitespace.
    - buserror 3y ago
      It doesn't requires a space, you could modify the lexer to recognize '..' as a prefix and solve that problem, it's just a choice they made to refuse that it could be implemented by just having one character forward looking lexer. It is not because it is implemented like that in gcc (requiring a space, possibly so they didnt have to modify the lexer) that it ought to be specced like that.
      - teo_zero 3y ago
        All C lexers are greedy, i.e. they extend the current token as far as they can. So "0..9" is split as a token "0." (numeric literal) followed by token "." (operator) followed by token "9" (numeric literal). To do what you suggest, the lexers would need a major redesign, not just a small change.
  - avar 3y ago
    C still supports EBCDIC, and other potential non-ASCII character sets one might invent in the future. It promises e.g. that 0..9 is contiguous, but e.g. "case 'A' ... 'Z'" would behave differently.
quelsolaar 3y ago
Im in the wg14 and this is not true. The later versions of the C standard are not dependable and diverges quite a bit from implementations. There are lots of things in the C standard text that you should not depend on. There are in fact extensions that are more commonly implemented than standard features, and some standard features that hav no known implementations. I hope to work on a guide for developers who want a “dependable-C” where they can guarantee it will compile and run correctly in as many implementations as possible.