Nice summary. Out of curiosity:

Why are those warnings not automatically included in "-Wall -Wextra"? Is there any issue with enabling them? Are these somewhat experimental?

How do these GCC warning compare to Clang warnings? Do these warnings exist there, too?

> Why are those warnings not automatically included in "-Wall -Wextra"? Is there any issue with enabling them? Are these somewhat experimental?

Because tons of people keep complaining "muh my build breaks if they enable new warnings". Dammit, idiots, if your build break there's a good chance your software is already broken too; that's the point of breaking the build: making bugs visible so that you have to fix them.

That's why you don't enable -Werror in release builds, contrary to received wisdom on the subject.

When you compile with -Werror, you surrender control over your build's success to the whims of the same people who think that it's okay that memcpy(0, 0, 0) is undefined behavior. The personal opinions of future compiler authors shouldn't affect whether your program builds successfully. Sometimes warnings are bogus.

Sure, use -Werror in development. But don't make it the default.

> The personal opinions of future compiler authors shouldn't affect whether your program builds successfully.

So, let's say that you find some 2003 software on some deep corner of SourceForge that you want to use.

Would you rather :

* Have the build fail because new warnings were introduced ? * Have the build succeed and then get crashes at runtime because the behaviour of the compiler changed anyways and the program was rendered invalid ?

I'll personally always want the first one.

There's a name for a kind of change that makes a previously correct program incorrect: "compiler bug".

the program wasn't "previously correct", else a new, but still language compliant, compiler would build it just fine

Worth noting that some warning flags (at least when combined with -Werror* ) make the compiler not standard compliant.

* It's been some time since I last partook in language lawyering, and can't remember if standard compliant C compilers are allowed to produce diagnostics, the term used, for well-defined code as long as they also succeed.

Perhaps what we really want is a flag to cause the compiler to error for code that would produce undefined behavior and give warnings for the rest? Turning all warnings into errors is a great "worse is better" technique but it seems a bit too coarse-grained to me.

Alas, undefined behaviour in C++ and C is in general not that easily detected..

It's true, but there's a few tools out there to help now, such as tis-interpreter (https://github.com/TrustInSoft/tis-interpreter)