> I am not aware of any well defined parts of the C standard where GCC and Clang disagree in implementation. Only in areas where things are too vague
well, the part of the standard that are vague and/or underspecified is a very large "Here be dragons" territory.
Time-traveling UB, pointer provenance, aliasing of aggregated types, partially overlapping lifetimes. When writing low level codes, it makes sense to know how exactly the compilers implement these rules.
In particular, regarding aliasing, GCC has a very specific conservative definition (stores can always change the underlying type, reads must read the last written type) that doesn't necessarily match what other compilers do.
>> It isn't, but it is a family of languages that share a lot of syntax and semantics.
> I am not a C/C++/C#/ObjectiveC/JavaScript/Java programmer.
C#, Java, JS share a bit of syntax, but certainly not semantics. ObjectiveC/C++ definitely belong. There is a trivial mapping from most C++ constructs to the corresponding C ones.
> well, the part of the standard that are vague and/or underspecified is a very large "Here be dragons" territory.
Sure, but the answer as I said earlier is: don't touch those parts of C.
The subset which _is_ well defined is still perfectly powerful enough to write highly performant software.
It's not like I'm advocating for you to use the brainfuck subset of C.
> When writing low level codes, it makes sense to know how exactly the compilers implement these rules.
Almost nobody is writing C low level enough for this and I've written embedded code which didn't need to worry about strict aliasing.
This is again just a misconception, almost no real programs need to delve this deeply into the details.
> In particular, regarding aliasing, GCC has a very specific conservative definition (stores can always change the underlying type, reads must read the last written type) that doesn't necessarily match what other compilers do.
It doesn't matter what other compilers do as long as in terms of the abstract machine these differences do not break the rules set out in the standard. Again, you do not need to know these details for 99.99% of program code.
> C#, Java, JS share a bit of syntax, but certainly not semantics. ObjectiveC/C++ definitely belong. There is a trivial mapping from most C++ constructs to the corresponding C ones.
There's a mapping from any of these languages to any other one, in some cases also quite trivial, the amount of overlap is immense, but C and C++ have heavily deviated.
I am a C expert, I do not claim to be a C++ expert, every time I look at C++ I am increasingly surprised at just how it redefines something core about C. Something I just learned in this very thread is https://en.cppreference.com/w/cpp/memory/start_lifetime_as which doesn't exist in C because apparently C and C++ define object lifetimes completely differently.
It's dangerous to keep pushing this notion that C and C++ are very similar because it leads to constantly leads to expert C++ programmers confidently writing subtly broken C code and vice versa.
well, the part of the standard that are vague and/or underspecified is a very large "Here be dragons" territory.
Time-traveling UB, pointer provenance, aliasing of aggregated types, partially overlapping lifetimes. When writing low level codes, it makes sense to know how exactly the compilers implement these rules.
In particular, regarding aliasing, GCC has a very specific conservative definition (stores can always change the underlying type, reads must read the last written type) that doesn't necessarily match what other compilers do.
>> It isn't, but it is a family of languages that share a lot of syntax and semantics. > I am not a C/C++/C#/ObjectiveC/JavaScript/Java programmer.
C#, Java, JS share a bit of syntax, but certainly not semantics. ObjectiveC/C++ definitely belong. There is a trivial mapping from most C++ constructs to the corresponding C ones.