Linux kernel community protests about treating compiler warnings as errors
theregister.com
theregister.com
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.
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.
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".
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.
Some warnings can hint about serious issues (e.g. dangerous casting). This can lead to bugs with very serious consequences.
Disclaimer: I am not a big fan of phoronix, but honor to whom honor is due.
That was not the case.