Linux 5.15 Enabling "-Werror" By Default For All Kernel Builds

[oiaohm]

Depends on what you mean by "all warnings". Some developers tend to be fairly aggressive, in terms of which they enable. Unfortunately, the more advanced warnings tend to be less reliable, which becomes problematic when someone decides to enact a -Werror policy.

This total here I do not agree with. The error rate of more advance warnings is not that high.

https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html

There are the Diagnostic Pragmas in gcc clang and other compilers to selectively turn off the advance warnings in case of a false positive.

The problem here the worse of the more advance warning has less than a 10% false positive rate. So yes less reliable but is it justifed not to enabled it comes at the cost of letting the 90% of the detections when its right past past.

Yes it pain to code to selectively turn the advanced warning off when the compiler is truly wrong.

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
foo(b); /* no diagnostic for this one */
#pragma GCC diagnostic pop

But we should be looking at 3 lines of code max per compiler to correct a advance warning false positive.

The case where it turns into horrible ruining code is when the person doing the repair does not see the problem as a false positive the cause of this is the fact over 90% of the time the advanced warning is right there is a problem and the code does need to be changed. Yes when the code does need to be changed because the error is real there is the equal problem

What you say next coder:

I've seen significant amounts of time wasted, and bugs actually getting introduced, in the course of fixing false-positive warnings (i.e. those which didn't indicate any real problem). In many instances, the resulting code is worse, in terms of being less readable or maintainable. I would argue that most of these warnings shouldn't even have been enabled.

You can take away the false positive and put when the warning are correct. We have the same set of problems where the people fixing the code make the code worse and less readable or maintainable.

This is about having people doing the repairs know what the heck they are doing. Lot of people don't understand how little code is required to turn off advance warnings selectively. Yes there is a big problem with people not having the skill to work out that something is a false positive that should be a 3 line patch or less and should be reported to compiler so they can fix it.

I've also seen developers take the easy way out. Such as getting rid of unused variables holding return code values, rather than actually checking them and handling errors appropriately. But hey, the warning count was reduced, so the code must be better!

https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

__attribute__ ((warn_unused_result))

The fact a developer can do that is a different bug in the code. Yes warn_unused_result on the function means removing unused variable holding return values still equals warning/error. Yes MSVC has equal declare on functions as well.

We do need to get in the habit when coding to put proper attributes on functions so that function that return import error codes or results that must be freed cannot black holed causing future issues.

[coder]

I'd say fixing all warnings saves debugging time overall, in the long run.

Depends on what you mean by "all warnings". Some developers tend to be fairly aggressive, in terms of which they enable. Unfortunately, the more advanced warnings tend to be less reliable, which becomes problematic when someone decides to enact a -Werror policy.

I've seen significant amounts of time wasted, and bugs actually getting introduced, in the course of fixing false-positive warnings (i.e. those which didn't indicate any real problem). In many instances, the resulting code is worse, in terms of being less readable or maintainable. I would argue that most of these warnings shouldn't even have been enabled.

I've also seen developers take the easy way out. Such as getting rid of unused variables holding return code values, rather than actually checking them and handling errors appropriately. But hey, the warning count was reduced, so the code must be better!

[boxie]

This does not change the bar for code getting in.

true - it also helps devs too using defaults. it might be one less patch cycle they need to submit - which will also make maintainers jobs easier.

[brad0]

Why? Linus has *never* tolerated warnings in his builds. It is for the increasing number of robots test building things that might otherwise not flag a warning. So hopefully the warnings will be less likely to make it to him. Did anyone even read the article?

Linus' comment at the bottom makes it clear how stupid the situation is and why this should have been done a long time ago.

[indepe]

I'd say fixing all warnings saves debugging time overall, in the long run. However that might apply more to writing/maintaining new code than to (re-)building existing code that you wouldn't debug anyway.....

It's probably a time saver especially for Linus and other maintainers who need to go through source code written by thousands of engineers.

[brad0]

(I say that with no inside knowledge, however)

That is very evident.

[perpetually high]

Except this was apparent 20 years ago.

Fair, but the kernel and kernel development seems to have been doing good so far. (I say that with no inside knowledge, however)

The Linux kernel is a really interesting beast. There's no benchmark for it. Nothing to compare it to. Stands on its own mountain.

With that, it's hard to say what's the best way. Linus literally made git because svn wasn't sufficient for Linux. Now look at git. Now look at GitHub. Now look at everything.

I'm so impressed with the Linux kernel, GNU/userspace, all of it. I'm trying to do my best to give back now. With as little complaining, and more doing.

[perpetually high]

or - and hear me out here - getting devs to write code that is of better quality is just a net positive.

true that it is is a bit of an annoyance, but that helps you (the dev maintaining the code) in the long run.

As an example - there are no warnings in Golang, it's either an error or not worth surfacing - unused variables are errors, unused imports too.

I never once thought of things being "more secure" because I have no errors.

I just want my code to run. I suspect this will be the same kernel devs - the bar to getting new code in is just a little higher and while you might trip over it a few times, you train yourself to not to do the things and you are back to clearing the bar easily.

net positive!

Gross annoying, net positive : )

Yeah, but it's just a thorn in the side and maybe slows them down. I'm not disagreeing so much, I just don't think it should be a default behavior. More opt-in. But again, I understand why Linus did it, and it's worth experimenting to see what happens, and if it works out well, then experiment successful.

[Sonadow]

I don't care about Linus's explanations, this thing stays off in my custom builds.

[boxie]

Very true, and I think this is a great argument against it.

or - and hear me out here - getting devs to write code that is of better quality is just a net positive.

true that it is is a bit of an annoyance, but that helps you (the dev maintaining the code) in the long run.

As an example - there are no warnings in Golang, it's either an error or not worth surfacing - unused variables are errors, unused imports too.

I never once thought of things being "more secure" because I have no errors.

I just want my code to run. I suspect this will be the same kernel devs - the bar to getting new code in is just a little higher and while you might trip over it a few times, you train yourself to not to do the things and you are back to clearing the bar easily.

net positive!