Hacker News Reader

> Unfortunately it's not as simple as always enabling -Werror:

I was already bitten in the backside by Werror. Allow me to tell you how.

I was working on a legacy C++ project and my employer uses an in-house build system that automatically builds the whole dependency tree if any dependency changes. A previous team was a staunch supporter of the "no Werror considered harmful" philosophy, and made it their point to even pass it to unit tests.

That's all fine and dandy, except compilers are upgraded and older compiler versions are deprecated out of our reach. Consequently, when I did a minor update to my project and launched a build job, the entire dependency tree started failing left and right, throwing a million error messages as a packed wall of text. The root cause? The current version of GCC was updated to throw warnings regarding some inane drivel involving white spaces, and with Werror passed everywhere those were upgraded to full blown errors.

The end result was a couple of weeks wasted going through the dependency tree to tackle warnings, because otherwise the build pipeline failed spectacularly.

> inane drivel involving white spaces

I suspect you wouldn't enjoy Python.

Treating a stylistic warning as an error is completely different than a semantic error being an actual error.

This is not a reason to avoid -Werror, but a reason to approach changes in nontrivial build environments like one would approach significant changes with the software itself.

> This is not a reason to avoid -Werror

Sorry but it really was. Passing Werror like confetti was the root cause of a problem that led to two weeks of downtime and added absolutely no value at all, and the solution consisted of addressing said warnings alone. And if there was any doubt, the upgrade was undoubtedly trivial, mainly due to the fact that the project still targeted C++11, and with exception of the Werror nonsense was absolutely flawless.

> and the solution consisted of addressing said warnings alone.

Alternative solutions which should not have taken two weeks would've included:

    -Wno-inane-drivel-involving-white-spaces
    -Wno-error=inane-drivel-involving-white-spaces

Just because you're using -Werror doesn't mean literally every single warning in the compiler ever should be a hard error. It means errors should be the default, allowing you to opt-out of stupid warnings-as-errors, rather than needing to opt-in to critical warnings-as-errors.

If the team that owned these dependencies were militant enough to enable Werror for tests, they might have also insisted that the warnings be fixed properly instead of being suppressed.

I have had instances where upgrades of the compiler added bugs, or where warnings identified new potential bugs. And not always revolving around the error flags either.

The update after analysis and probably some retesting concluded as trivial, but before undertaking the change I think it has a risk of having the same impact as a change of software.

It’s not -Werror at the root of this general work (yes it turned that way in this specific case), but the analysis and recheck after was the core work from the compiler upgrade.

This seems like your compiler toolchain definition should have been a part of your build system's graph. I do this exact thing, with -Werror on, and bumping to a new gcc version or clang version typically exposes new errors that will be blocking on gerrit until I fix the corresponding now warning code. Bazel makes this easy, but you can definitely do it with CMake or other systems too.

> some compilers issue different warnings based on compile settings

Also based on which platform they're run on.

> new compiler versions regularly introduce new warnings,

Much worse, IMO is older compiler versions which emit incorrect warnings. At least when a new version emits a new, correct, warning it's at least something you want to fix (or disabling a new unhelpful warning). The failure to compile may still be a practical problem but at least the direction it creates is a right one.

For older compiler versions, there may be no fix-- breaking the code or turning off the warning may be the only options if Werror is used.

Outside of heavily controlled environments, I think Werror is just plain toxic. Want to run it on your CI builds where you don't need to worry about the compiler being upgraded or downgraded without warning? Great! Everyone should do that. Being warning clean on your primary target toolchains(s) is an important move.

For code distributed to users the use of Werror use creates a pressure against introducing new and helpful warnings for compiler authors. Fortunately, it's such a nuisance for code distributed to others that no one survives enabling it for long and the worse damage it likely does is that the few projects that use it for publicly distributed code refrain from enabling many otherwise useful non-default warnings.

This is why I use `-Werror` in maintainer mode but not otherwise.

-Wsign-compare is a typical example of warning that implies a serious error unless you prove it couldn't happen; spending, typically, more effort than would be needed to actually fix the warning.

Well yeah, but then there's stupid design warts like size_t being unsigned, and it's much too late to fix this now.

How many objects of negative size are you typically dealing with?

This isn't the problem, but that it almost always makes sense to use signed math for computations (including computations that involve sizes). And mixed-sign-math in a language that doesn't have robust over/underflow detection but implicit conversion between signed and unsigned is usually a very bad idea. The only advantage that an unsigned size_t gives is one bit more range (but these days this is irrelevant - 63 bits ought to be enough for anyone). But this topic really has been discussed to death in the last decade or so :)

> dependencies are usually full of warnings > locally supressing warnings in dependencies

I don't see any reason to enable warnings for dependencies in your project's build system. I suggest building dependencies with (as much as possible, considering ABI compatibility) their own preferred compiler flags (and ideally, with their own build systems), and use your compiler's equivalent of `-isystem` to suppress warnings in their headers.