Re: Undefined Code in .../include/linux.bitops.h

From: Jeffrey Walton
Date: Wed Feb 20 2013 - 12:21:41 EST

On Wed, Feb 20, 2013 at 11:10 AM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote:
> Jeffrey Walton wrote:
>> is a tough read, and Item 4, "I think I found
>> a bug, how do I report it?" does not tell me how to report this.
> From that page:
> | A bug is when something (in the kernel, presumably) doesn't behave the
> | way it should
> So just tell us what it is that doesn't behave the way it should.
>> According to Section 5.8, "Shift Operators" of
> The kernel doesn't try to be fully standard conformant.
>> return (word >> shift) | (word << (32 - shift));
>> "The behavior is undefined if the right operand is ... equal to the
>> length in bits of the promoted left operand."
>> If I ask for a shift of 0
> Does the kernel ever do this?
>> the various ops will perform `32 - shift` (or `64 - shift`, etc). That
>> means the right operand *IS* equal to the length in bits of the
>> operand, so the code is undefined.
> In practice, what CPUs actually do is to shift either by zero or by the
> full 32/64 bits. Both implementations give the correct result.
Well, a few things come to mind.

First, the language is C and the kernel needs a compiler. The compiler
might try hard to be C conforming. I could be wrong, but all that
would be needed to break exiting code in some cases is better
analysis. So the kernel is betting on a component it clearly does not

Second, I know that code will not work on some older processors that
do not mask in its barrel shift as expected. I doubt they will be
encountered today, but you never know. In addition, future processors
may not offer the same [tolerant] behavior of current processors.

Third, depending on non-standard behavior is a usually bad choice over
the long run (not withstanding the comment on being non-conforming).
Fedora/Adobe/Flash and glibc/memmove comes to mind

Fourth, user land programs use the header too. This is expected
because programmers are taught to reuse existing code. Unfortunately,
many user land programmers lack the knowledge and experience of a
kernel hacker, so they won't realize a potential minefield exists or
how to navigate the minefield.

Finally, I think its poor mentoring. Many junior programmers look up
to experienced kernel programmers, and I think its poor leadership to
provide them with bad habits. Obviously, this is just my opinion, and
does not warrant a response.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at