Linux 5.15's New "-Werror" Behavior Is Causing A Lot Of Pain

[andreano]

Yesterday everyone over joyed with -Werror being the best thing to ever happen to Linux Kernel and anyone who opposed that view does not know anything about coding! Now that it's reverted ... sorry demoted, everyone again starts to see why it wasn't a well-executed idea after all. Typical cult behavior.

Lol, there is some truth to that (it's easier to be politically correct), but I would say the fundamental reason why this can not work (not necessarily why it was demoted) was pointed out so well already in the fourth post that there wasn't much point in repeating it.

[indepe]

Some part of this discussion seems to be about if it is ok to write code that produces warnings. However for the kernel, that was already decided long ago and this decision has not changed. The policy is still "no warnings" without ifs and buts.

So to me it seems that for those cases like very old or very new compilers, or unusual configurations, it just needs to be possible to change the default without too much difficulty. Perhaps including a permanent setting per machine/user. Otherwise it is just a matter of getting from A to B, since there still seem to be areas where warnings occur during normal work (and it doesn't seem obvious if there is a specific reason other than lack of attention). So it seems that takes a few smaller steps instead of a single big one, but so far I haven't heard a convincing reason why -Werror shouldn't be the default for the kernel eventually. Certainly there should be something in place that prevents the situation where Linus and other maintainers too often have to deal with warnings that are not theirs to fix.

[uxmkt]

Let that be a lesson to all the userspace projects who stupidly thought unconditionally enabling -Werror being a good idea.

[l8gravely]

This should be a net positive. A warning that is a nuisance either shouldn't be a warning (compiler should be fixed), or, it is a warning and the code should be fixed.

Its going to take time, but getting this in front of people and forcing it will have a ton of short term pain, but in the long term it will lead to better things. Having compile warnings is just silly in this day and age. If the code doesn't compile cleanly, it shouldn't be merged.

No, this doesn't fix all problems, it just addresses the simpler ones, which are still important to address.

[Markopolo]

Some part of this discussion seems to be about if it is ok to write code that produces warnings. However for the kernel, that was already decided long ago and this decision has not changed. The policy is still "no warnings" without ifs and buts.

So to me it seems that for those cases like very old or very new compilers, or unusual configurations, it just needs to be possible to change the default without too much difficulty. Perhaps including a permanent setting per machine/user. Otherwise it is just a matter of getting from A to B, since there still seem to be areas where warnings occur during normal work (and it doesn't seem obvious if there is a specific reason other than lack of attention). So it seems that takes a few smaller steps instead of a single big one, but so far I haven't heard a convincing reason why -Werror shouldn't be the default for the kernel eventually. Certainly there should be something in place that prevents the situation where Linus and other maintainers too often have to deal with warnings that are not theirs to fix.

Worth pointing out there’s a difference between a policy of no warnings and enforcing that any warning means the build fails.

That code was getting to Linus (presumably signed off by the appropriate maintainers) but still had warnings demonstrates just how hard it is to know that a piece of code *never* emits warning for all kernel configurations and architectures.

if Linus wants -Werror by default then they first need CI build bots to test build against many different kernel configurations, target architectures and supported compilers/versions. Tossing it in during the middle of a release after a day of frustration was not ideal.

Eventually, they’ll end up merging code that turns out has build errors when options X/Y/Z are enabled and GCC or LLVM A.B.C is used.

the most aggressive long term strategy I can see working out without massive downstream pushback is where the only configurations and compiler versions where Werror gets enabled by default would be ones that have said build bots explicitly testing each one.

seems that they’ve rightly demoted the config to only trigger for BUILD_TESTING. I’m curious if any distributions will actually enable Werror for their own build servers. Would be great if they could get their eventually.

[pal666]

Different gcc versions print different warnings. Other gcc versions have buggy warnings.

don't use old gcc versions

[pal666]

They should *not* be fighting the compiler. They should spend their time writing awesome code. (which the compiler "warnings" are there to help assist). I think we're overthinking this.

you are completely wrong. warning without -Werror is just a noise, nobody will look at it. so compiler can't help them and they will spend their time debugging their horrible code

[pal666]

Like in 5.15 builds 5.15.1 builds 5.15.2 wont build because there was a llvm update that now creates a feature deprecation warning. Badumm.

go back to 5.15.1 and fix warnings, what's the problem? llvm before implementing new warnings should also test them on open source projects

[pal666]

That code was getting to Linus (presumably signed off by the appropriate maintainers) but still had warnings demonstrates just how hard it is to know that a piece of code *never* emits warning for all kernel configurations and architectures.

no, that means that warning without -Werrors don't work and everyone knows that. it built successfully, so the code must be good for linus

[oiaohm]

Compilers absolutely warn about language-defined behavior too, and it's not even all that useful. Example: -Wsign-compare: It's not like integer promotion rules aren't perfectly defined by the language. I would go as far as to say that when it comes to equality comparisons (where signedness of comparison is not even a thing), this warning is 100% detrimental: There is only one interpretation – the intended one, so there is nothing to whine about, all seasoned programmers know the integer promotion rules anyway, and it is detrimental, because "fixing" the code by adding explicit casts makes it not just less readable but more brittle.

That of comparing signed and unsigned is highly brittle. C standard does not define that signed will always use most significant bit (MSB). There are platforms with LSB signed as in least significant bit.

andreano there are a lot of C warnings like sign-compare that happen to be about items that are undefined in the C standard some of them are things you would not think of that sign integer binary form is not defined in the C standard.

https://en.wikipedia.org/wiki/Protocol_Buffers from google was designed on a LSB signed platform.

https://developers.google.com/protocol-buffers/docs/encoding

They give it a cool name zig zag encoding. But it really LSB signed. Yes -2=3 as zig zag encoding does is a valid thing to happen when you do a sign to unsigned compare in C just people are not use to seeing this because they don't use LSB signed platforms. Sign-compare warning is in the same class as different warnings about endianness.

There is a problem here a lot of your seasoned programmers are only taught about MSB based signed never taught about LSB signed or the other odd ball forms. andreano you are one of them there is not a solid integer promotion rule. There is a dominate signed int type being MSB signed but the C standard does not mandate this. Neither does gcc or llvm there are architectures with gcc and llvm that are LSB signed.

So yes sign-compare is about undefined behaviour in the C standard that can catch you out.