The new warnings also tend to be increasingly asinine, and I remember an instance where two warnings happened to be in direct contradiction to each other, making it impossible to satisfy them both without some extensive and absolutely useless rewriting of the code.

I think one was about superfluous parentheses, and the other about not parenthesising an expression because it assumed the programmer would be too stupid to know the precedence of operators.

Rubocop is so bad about this. I can't believe people still use it. I spent 2 hours refactoring perfectly legal code to satisfy a code review and then found the suppress warnings invocation and ended up shipping that.

As someone in a DevOps role who has three times been the steward of major migrations between baseline OS versions, I have often been frustrated at teams who have hard-coded -Werror into their build configs, thus forcing me to jump through hoops to patching it out because the new compiler has some trivial complaint about this or that and the build is uncompileable on the new target.

I understand the noble goal of being warning-clean, but I wish there was a way to implement it in such a way that it could also be globally disabled. Then I could get a top level build, but the local resolution of the issues would still be on the owners of the code.

Zero warnings is the kind of thing that should be enforced as a pre merge check rather than a build showstopper.

In the case of the team moving to a new compiler, what are you suggesting? We can’t merge in use of a newer compiler until there are zero warnings in all our products? Who “fixes” all those code bases? Who touches the pieces of code that were last touched 5 or 10 years ago?

Various solutions are possible, including the obvious one of just removing -Werror. But the point is that this decision should be made by the team that owns/maintains the code, not by some centralized devops group.

Yeah, 100% agree. Or even better, for incremental improvement, have it enforce no new warnings.

But all of this requires adding complexity and branching to the system. It can be done and is worth doing, you just have to choose your battles.

> It's easy to imagine having a compiler upgrade [...]

Not in OpenBSD it isn't.

Since the move to Clang/LLVM the compiler in OpenBSD has been pretty up to date.