Linus Torvalds admits to 'self-inflicted damage' with -Werror as Linux 5.15 rc1 debuts

Linus Torvalds has loosed the first release candidate for version 5.15 of the Linux kernel, though isn't sure if it's a big 'un or nothing to get excited about. "So 5.15 isn't shaping up to be a particularly large release, at least in number of commits. At only just over 10k non-merge commits, this is in fact the smallest rc1 …

[GrumpenKraut]

Re: Shift / bitwise operators

> On shifting vs. multiplication, I once worked with a very interesting system where doing something like x*=2 was actually faster than x<<=1

I can only suggest to also always try the unoptimized code and see what the compiler makes of it. Many optimizations that were OK two decades ago are actively bad today.

I meanwhile stopped to do the shift-for-multiply stuff because the compiler outsmarts me as a rule. Compiler-writer-appreciation-pint ---->

With platforms/compilers where the optimizer is not so great things may well be different.

[Brewster's Angle Grinder]

There's plenty of hacks I've retired. For example, I used to write flow control as arithmetic, but branch prediction has neutered that.

On the other hand, storing lookup tables in registers has grown in usefulness as the processor width has expanded. 64 bits is like 8 bytes - half the words in this post don't have that many letters - so imagine a whole 8-byte table in a register!

Here's another one from the old time book:

x => x * 0xcd >> 11

Obviously you need one of those fancy, modern high-end processors that can multiply two 8 bit regs and store the results in a composite 16 bit reg. But it's good for all 8 bit values. (I've written the shift as 16 bits but you discard the low byte reg and do a three bit shift on the high one.)

If your chip doesn't have a hardware multiply instruction, other constants may be preferable, depending on the range of input.

And while this was essential, back in the day, it remains perfomative today in many situations.

[jake]

"once an asm programmer"

Once an asm programmer, always an asm programmer.

Have a beer. It sometimes helps.

[Richard 12]

The warnings aren't always bad code

That's why they're warnings, not errors.

What they're supposed to do is get you to look at the code, because it usually means somebody made a typo.

Eg a flow clause that has no effect or is constant is almost always a mistake.

What some people do is just turn off the warning.

[ghp]

Re: The warnings aren't always bad code

"Some people", as in "all developers" ?

[gnasher729]

Re: The warnings aren't always bad code

In my current project, there are exactly two warnings turned off: One where the compiler tries to tell me that using a semaphore is inefficient (when the efficiency is totally of no concern, and the workaround would be an awful lot of work and very hard to get right), and one where I intentionally crash the program, like * (int *) NULL = 0; and the compiler won't let me do that without a warning.

[spuck]

Re: The warnings aren't always bad code

Your use case seems very unique, but turning off _any_ warning of null pointer references seems like a high price to pay to gain the ability to intentionally crash the program.

[Someone Else]

Re: The warnings aren't always bad code

Hmmm...can't you simply SIGINT or raise an interrupt known to shut down the beast?

There was a point in a past lifetime where I needed to crash an embedded program if all hell broke loose unexpectedly, so I simply divided 0 by 0. The code reviewers never quite got their arms around that, even with full commenting. So I reverted to calling a trap instruction that would crash the program.

_{It was a while ago, and recollection is faulty, but I might have called the trap instruction that fielded division by zero...}

[Bill Gray]

Re: The warnings aren't always bad code

Hmmm... hadn't tried such a thing, but

int main( void)

{

*(int *)0 = 0;

return( 0);

}

compiled with gcc -Wall -Wextra -pedantic -o z z.c got no warnings. Chalk one up for clang, though; it realized this was a no-no and warned me. However,

int main( void)

{

int *null_ptr = (int *)0;

*null_ptr = 1;

return( 0);

}

slips past both compilers without warning. (A thank-you to jake for reminding me that one can use HTML tags on these fora.)

[Warm Braw]

Re: The warnings aren't always bad code

The issue (as has been alluded to above) is that we don't have a strong semantic definition of what constitutes a "warning". Warnings live in an ambiguous space between supplementary "information" and actual "error" and, depending on circumstances, could be either. Or both.

If you've simply written something that's ambiguous or confusing, clearly the correct thing to do is fix it to eliminate the message - but, more importantly, to clarify your intent for others.

But what about "Warning, Feature X is deprecated"? You know it's deprecated, but you know it's still supported. Rewriting the code may require further changes you don't want to make now, but turning the warning off would perhaps mean a future developer fails to make the change - this is a scenario that I've come up against in practice (though not with gcc).

Perhaps, in an ideal world, you would be able digitally to sign-off certain lines of code as being acceptable for a certain length of time so you could have clean builds for the lifetime of the waiver without losing the longer-term tripwire.

[HereIAmJH]

Re: The warnings aren't always bad code

Eg a flow clause that has no effect or is constant is almost always a mistake.

Are you sure, because my uni C instructor started every main() with while(1).

Of course, he also explained memory allocation by comparing them to CoBOL PIC statements.

[Anonymous Coward]

Re: The warnings aren't always bad code

Then he didn't know C very well.

for(;;)

will have the same effect, but compile with no warning.

[gnasher729]

No, I wrote some perfectly fine code. I wanted to check that 0 ≤ i < n, so I wrote the obvious code. If I don't write "i >= 0"then some reader will assume that I forgot to check the lower bound.

The second code was not worse, it was an obvious workaround against the compiler's stupidity. And ran into another stupid rule of the compiler, where it assumes you don't know the relative priority of || and &&.

Hope that explains it. As for criticising, well, I assume that I know better than you any day.

[jfm]

Again: it's an unsigned integer. The test (i >= 0) is always true. In fact I'd expect the compiler to optimise it away; and I can see why it would also warn that it doesn't make sense.

[bombastic bob]

No, I wrote some perfectly fine code. I wanted to check that 0 ≤ i < n, so I wrote the obvious code. If I don't write "i >= 0"then some reader will assume that I forgot to check the lower bound.

if(myvar < limit) //myvar unsigned, always >= 0

maybe THAT ^^^

[Anonymous Coward]

You should never assume operator precedence. It varies between languages. Even if you know it, the people maintaining your code in the future might not know it. Or they they might not know that you know it. In the interests of readable code, always insert extra parentheses to make it clear what you are intending.

ie.

if ((value < lower_limit) || (value > upper_limit))

is more readable than

if (value < lower_limit || value > upper_limit)

Even though they compile to the same code

Just try writing the second form in Delphi/Pascal and you will come unstuck.

[heyrick]

Upvote, because people that have looked at my code have in the past whinged about too many brackets.

As you say, operator precedence isn't a fixed immutable thing. It changes depending on the language in use. Therefore, writing code with additional brackets not only makes it extremely clear what relates to what, it also means one isn't relying upon said precedence.

[Anonymous Coward]

Warning are by definition not errors, so they shouldn't be treated as such. It's always good to write code that doesn't generate warnings, but some brain dead compilers generate warnings for the most idiotic of reasons. Of course you can usually restructure the code to remove the warning, but sometimes there are good reasons for not doing so.

[Will Godfrey]

Never ignore 'trivial' warnings

I've learned that what may seem trivial on the face of it has a habit of biting you at the most inconvenient times. Yes, I have seen a warning and thought 'that will never happen'... until it did!

[bombastic bob]

Re: Never ignore 'trivial' warnings

sometimes warnings will point to actual errors in the logic, too. Even though it worked when you tested it...

or when you fix the warning, the logic error becomes visible.

[trevorde]

No good work goes unpunished

Worked on a product where we decided to fix all the warnings. One dev slaved away for a fortnight and fixed *most* of the warnings. He found a few errors, so it was actually worthwhile.

The only place he couldn't fix the warnings was in some test code which achieved 100% code coverage on what it was testing. We decided to just disable 'warnings as errors' on that test code and chalk it up as a win overall.

[W.S.Gosset]

!! You mean : hyperPoliticallyCorrect, shurely