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

[Jeffrey Walton]

On Wed, Feb 20, 2013 at 11:10 AM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote:
> Jeffrey Walton wrote:
>> http://www.tux.org/lkml/ 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
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf:
>
> 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
control.

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
(https://fedorahosted.org/fesco/ticket/501).

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.

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/