I am not sympathetic. All the regular warnings are easily silenced by changes that are good programming practice, once demonstrated to be false positives. Each new warning after a change deserves any attention it draws.
New warnings about old code from new compiler releases often flag real problems.
The danger is that a big dump of warnings get silenced without proper investigation. It helps to start by patching the most-used headers, first.
Not that the article did a great job highlighting all of the good reasons that I and others pushed back against this but...
It's not like this is a small code base that's already free of warnings.
This is a massive code base under the most extreme churn, with 10^6000 configurations, supported by many versions of two different also-fast moving compilers adding more diagnostics to -Wall, with patches getting backported to forks ("stable"), without any CI or processes in place requiring any soak time on patches. (There are quite a few CI systems, but they don't gate merging; linux-next exists as an integration tree, but some patches skip it or spend a day or two before the merge window).
It's ok to not be sympathetic, but you really don't understand what we're dealing with here.
The problem boils down to compilers not having multiple classes of warnings. If you do an assignment in a conditional? Yeah, that's a good thing to warn the user about. Heck, that should be an error IMHO. But if I leave in a variable declaration, should my entire build crash to a halt because of the unused variable?
Presumably Google and any other engineering org of any value has their own set of warnings and errors layered on top of the clang/gcc warning/error output. We should try to learn from them, and carry that upstream, rather than bludgeon everyone over the head with a frankly simplistic "warnings bad mmmkay".
I remember building one program that was pretty big and was surprised that no warnings were issued, I seem to think it was postgresql but I'm not sure. I'll have to try another build sometime.
In my rinkydink c programs I try to understand the warnings and fix them, I do recall that they used to build clean but new gcc versions would note new issues that had not been flagged before.
If a developer is hit by this while having to deal with hundreds or even thousands of warnings: how would they know when a new warning is introduced in that massive pool of warnings? That seems very dangerous in the context of kernel development.
Some warnings can hint about serious issues (e.g. dangerous casting). This can lead to bugs with very serious consequences.
It's not entirely clear from the article. I can feel the pain of the maintainers if this was suddenly dropped on them. But the article slightly hints at that it was repeatedly communicated that werror will be enabled over a long period time. If this is the case they don't really have any grounds to complain.
New warnings about old code from new compiler releases often flag real problems.
The danger is that a big dump of warnings get silenced without proper investigation. It helps to start by patching the most-used headers, first.