@pdt The C spec being dead doesn't mean much, because you don't write for the theoretical spec, you write for the actual implementations. GCC and LLVM have regular releases, and they do break stuff. libc and OS header implementations do change.
@pdt Most C programmers I know are afraid of upgrading compilers, and even prefer to lock them down for the lifetime of the project.
@kornel @pdt either of the compilers intentionally breaking the standard in any relevant way would be a big no-no (only MSVC can do that, cause MSVC does not care about it's reputation as a compiler).
Bugs exist in all software, but that's just that, it's all best effort. If you file such a bug, you will be supported, and it will stay up for years if need be, even if you are the only one affected, nobody will call it a feature.
There might be many reason to not upgrade the compiler, but it intentionally breaking standards is not one of them. It's usually either "I rely on specific compiler optimization, because performance = correctness in my context" or "I didn't follow the standard myself, so am paranoid now".
And yes you are not allowed to form a pointer outside of allocated range, no not just dereference, yes form, compilers do care, it's all your fault, repent!
@namark @pdt LLVM and GCC are only standards-approximate on a best-effort basis. Plus, the C standard covers only small fraction of what "C" is in practice, which includes libc, posix, warnings, vendor SIMD headers, flags, build tools. Some subset of it being stable in theory != programming language being stable in practice.
@kornel As far as I know C is a programming language. If you want to redefine it to mean all those things you listed to suit your narrative I can't argue. By that metric I can say that every library ever written in C is part of C as a langauge.
Also one of those things is not at all like the others. libc is part of the language standard and must be implemented by a complying compiler and therefore is not subject to standard in the same way. It is free to rely on architecture specifics, because that's the whole point. And these occasional hardware specific things is the only subset. What you tried to call subset covers the majority of use cases of the language.
