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."
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:
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...
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.
To do what you suggest, the lexers would need a major redesign, not just a small change.
It promises e.g. that 0..9 is contiguous, but e.g. "case 'A' ... 'Z'" would behave differently.
Most other languages never supported EBCDIC or dropped it long ago.
(Also: 'A' ... 'Z' may not do what the programmer intended in most other languages, too. Even ignoring Unicode, quite a few encodings have accented letters that are outside of that range)
Can you explain what that is? There’s supreme awkwardness around allowing `auto int i;` at block scope to work as before (with `auto` being ignored), but I’ve stared at that proposal a fair bit and haven’t noticed such an exception there.
For instance this is valid Clang C23 code (and entirely C23 standard-compliant):
int i = 0;
auto p0 = &i;
auto* p1 = &i;
In GCC this code doesn't compile because GCC already had a simpler "C style" __auto_type extension which doesn't allow the form "auto*", but this behaviour is also entirely valid C23 ¯\_(ツ)_/¯.
(personally I prefer GCC's version as it makes more sense for C)
This will cause some head-scratching when code that builds on Clang doesn't build on GCC, especially since Clang usually tries to emulate GCC behaviour. But OTH I think/hope that C's auto will only be used when absolutely necessary in "type-generic" macros, and no "almost always auto" nonsense which was fashionable in the C++ world for a while.
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.