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

[Delgarde]

This is works for me. Lot of the warnings gcc spits out turns out to be serous when you in fact build in different architectures. So lot of cases a warning is completely broken functionality for someone else on some other arch.

If you code is running fine but has warning, it's likely your code is fragile, contains bad practise and only happen to run by luck.

Exactly right. Compiler warnings aren't always right — but they represent your toolchain telling you that it thinks there's a problem. A good developer pays attention to those warnings, and even if you end up suppressing some of them, you make sure you understand why the warning was occurring first. I mostly work in Java these days, and tools that can help spot issues like unsafe null handling can be a life-saver... they're sometimes wrong because they don't understand the context in which the code is used, but they're still incredibly useful for the much larger number of cases where they're right.

I remember when 64-bit architectures started becoming more common, and the substantial number of issues that turned up when code was compiled 64-bit for the first time... it would have saved a ton of effort if the original developers had been paying attention to the various type-mismatch warnings they were getting.

[AMiguelTrindade]

I agree with this move. FreeBSD being compiled is a beauty to watch. There are simply no warnings (or, if there are, they are very rare).
Warnings in the compilation of a program should be considered as errors; it's the compiler telling us that probably that specific line of code could work in an erroneous fashion, although it is not necessary a compilation error.

[bug77]

With Linux it's even crazier than that sometimes. For example, I used to build custom Android roms, and simply building the exact same kernel source using a different gcc version would result in a kernel that would refuse to boot.

Do you think that could be traced back to the initial warnings the compiler was spewing out?

[briceio]

It isn't an easy question. But warnings are just... warnings. So by definition they shouldn't block anything. I think it would have been better to re-qualify some warnings in errors (some of them... not all). Because like it has been said: compiler changes add/remove warnings and some code written a few years back might need a refresh if, and only if, it generates an error.

[oiaohm]

It isn't an easy question. But warnings are just... warnings. So by definition they shouldn't block anything. I think it would have been better to re-qualify some warnings in errors (some of them... not all). Because like it has been said: compiler changes add/remove warnings and some code written a few years back might need a refresh if, and only if, it generates an error.

Gcc has warning to error flag for the very reason that there are valid reasons for the warning to block.

https://www.shutterstock.com/image-photo/sign-warning-dangerous-cliffs-325609661

Yes just because something is a warning does not mean you should ignore them be it software or the real world.

The reality here is code that generates a warning or error has always need a refresh. Linus technically put in the policy of zero warnings 20 years go. Reality is enabling -Werror is just enforcing the 20 year old policy.

[V1tol]

Warning means "i am compiler and i am not sure what is written here, i will compile it but not guarantee you will get result you expected". I am always trying to fix any warnings in my code, because sometimes fixing warnings can help to discover some mistakes. One of my favorite in C code - mismatched enum types, especially when the same case in different enums have different values.

[sdack]

Torvalds lacks much in people skills, but I do appreciate his coding attitude.

When a compiler throws a warning does it not only mean it could be bad code, but it also means the compiler is not sure about what is being done in the code, which subsequently means the optimizers will neither. So fixing warnings does not just fix possible bugs, but it also may lead to better optimizations.

[MrCooper]

This is a rare case where Linus was simply wrong.

Enabling -Werror by default is bad because it causes pain for lots of people, most of which have no responsibility for or even control over the factors which result in compiler warnings.

The right place for -Werror is in CI which gates merging changes. That way it causes pain only for developers who try to merge changes which result in warnings.

[bug77]

It isn't an easy question. But warnings are just... warnings. So by definition they shouldn't block anything. I think it would have been better to re-qualify some warnings in errors (some of them... not all). Because like it has been said: compiler changes add/remove warnings and some code written a few years back might need a refresh if, and only if, it generates an error.

It's context dependent. For example, generally speaking, a compiler can warn you if a function is not called. But if what you are compiling is a shared library, that may not be an issue, the function is there to be called by third parties. When compiling the kernel however, you are compiling a finished product, that function should be deleted.
Warnings may not be show stoppers, but they are certainly about code smells at the very least.

[sdack]

Enabling -Werror by default is bad because it causes pain for lots of people, most of which have no responsibility for or even control over the factors which result in compiler warnings.

You clearly have no coding skills whatsoever. When you cannot write C code in such a way that it makes a compiler happy then you should not write kernel code to begin with. Anyone who expects their code to be included into the kernel and to be used on billions of devices, but who cannot stick to the coding rules and requirements of the project, who cannot write code within the rule set of the C language, is simply out of their mind and rightfully should not have their code included into the kernel.

When you use a compiler that has not been recommended, perhaps because it is a very new, and as a result gives you warnings, should you be able to fix it and because you already know what you are doing, and not simply expect or hope for the code to work anyway despite it throwing warnings. Programming is not a gamble where you hope to get lucky, but it is an exact science.

Anyone who here wants to talk about the "pain of the developer" for having to fix their code is an idiot. You want to stick to Insta for the pseudo-emphatic BS on what is and is not pain. Programming is a challenge and a joy, and anyone who experiences it as a pain might be better off working in health care or social services where they can practise their empathy. Running test suits, compliance suits or customer acceptance tests has always been a part of the job in many areas. To complain about having to fix warnings and calling it a pain is preposterous.