On Mon, Oct 27, 2025 at 02:18:02PM +0000, David Laight wrote: > On Mon, 27 Oct 2025 21:12:00 +0800 > Guan-Chun Wu <[email protected]> wrote: > > ... > > Hi David, > > > > I noticed your suggested approach: > > val_24 = t[b[0]] | t[b[1]] << 6 | t[b[2]] << 12 | t[b[3]] << 18; > > Per the C11 draft, this can lead to undefined behavior. > > "If E1 has a signed type and nonnegative value, and E1 × 2^E2 is > > representable in the result type, then that is the resulting value; > > otherwise, the behavior is undefined." > > Therefore, left-shifting a negative signed value is undefined behavior. > > Don't worry about that, there are all sorts of places in the kernel > where shifts of negative values are technically undefined. > > They are undefined because you get different values for 1's compliment > and 'sign overpunch' signed integers. > Even for 2's compliment C doesn't require a 'sign bit replicating' > right shift. > (And I suspect both gcc and clang only support 2's compliment.) > > I don't think even clang is stupid enough to silently not emit any > instructions for shifts of negative values. > It is another place where it should be 'implementation defined' rather > than 'undefined' behaviour. >
Hi David, Thanks for your explanation. I'll proceed with the modification according to your original suggestion. Best regards, Guan-Chun > > Perhaps we could change the code as shown below. What do you think? > > If you are really worried, change the '<< n' to '* (1 << n)' which > obfuscates the code. > The compiler will convert it straight back to a simple shift. > > I bet that if you look hard enough even 'a | b' is undefined if > either is negative. > > David > > > > David
