| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <5124F571.4060503@ladisch.de> Date: Wed, 20 Feb 2013 17:10:25 +0100 From: Clemens Ladisch <clemens@...isch.de> To: noloader@...il.com CC: linux-kernel@...r.kernel.org Subject: Re: Undefined Code in .../include/linux.bitops.h 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. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists