Item — HN Reader

Yes, g++ -xc will call the regular C FE.

So yes, do not try to compile C code using a C++ compiler.

That you somehow get superior type checking with C++ is not really true anymore, as essentially all important parts were integrated into the C standard and the remaining should all exist as optional warnings in gcc. If you feel something is missing, please file a bug.

1 comments

The key logical jump here is "should", but in practice standards compliant C may still behave in unintuitive ways in edge-cases. It is not a compiler "bug" if functioning as defined, but rather a self-discipline issue to avoid shitty coding practices. =3

Just because a bit of C code compiles without diagnostics as C++ does not mean the code is safe. C++ does not have compound literals, but the syntax for a compound literal is accepted in several C++ compilers, including GCC and clang. However, in C compound literals have block-scoped lifetime, whereas C++ compilers give them expression-scoped lifetime. This means you can have silent use-after-free issues when using a C++ compiler. And, yes, I have encountered this (after diagnosing some read and write overflows in Valgrind and ASAN) and now try not to use compound literals in header files unless guarded to prevent accidental use with C++ compilers), though unfortunately this was a one of my later hard earned lessons.

Indeed, every C compiler including gcc is slightly different. Especially in the embedded space where pseudo-standards become a small subset of GNU compatible code very quickly. To be honest, gcc became the unofficial standard even with the GNU extensions.

Good C follows the 10 rules, uses old compatible macro language features, and is boring to trivially port. The "hold my beer" folks often go back to Python where the abstractions hide the foot-guns.

https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...

What specific examples do you have in mind where you would get a useful warning with a C++ compiler that you can not also get for C with gcc?

It had to do with the lack of helpful warning/error messages while porting over a C project. Switching out for libstdc++ was helpful in narrowing the scope of where to look for the issue, and a better idea of the failure mode.

Given the Sealioning problem on YC, trying to remember an edge case issue from years ago would not go well. If your work habits aren't pushing into the compiler standards gray areas, than one probably won't ever encounter such issues. ymmv =3

https://www.youtube.com/watch?v=T4Upf_B9RLQ