4 ms·
Nope, on 16-bit platforms a 16-bit left shift has a very different result from a 16-bit left shift on a 32 bit platform. It's basically a question about knowin
by guyzero 10y ago
Nope, on 16-bit platforms a 16-bit left shift has a very different result from a 16-bit left shift on a 32 bit platform.
It's basically a question about knowing when you'll get burned by the size of int varying.
- OMGWTF 10y agoSo? (i >= i) // 1 ((i >= i) << i) // 0x10000 or 0 (((i >= i) << i) >> i) // 1 or 0 (((((i >= i) << i) >> i) <= i)) // ((0 or 1) <= 16) == 1 Where did I go wrong?
- loeg 10y ago> ((i >= i) << i) UB.
- OMGWTF 10y agoAh, you're right. > If the value of the right operand is negative > or is greater than or equal to the width of > the promoted left operand, the behavior is > undefined" (http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf - ISO/IEC 9899:201x (C11 Working Draft N1570): 6.5.7 Bitwise shift operators)
- loeg 10y agoYeah. It seems like something easy to define to me, at least in the case the compiler can recognize the shift is a constant. But that's the standard for you.
- tspiteri 10y agoAlthough it wouldn't affect the result in this case, 1 << 16 could actually result in 1. For a 16-bit number, a processor can consider only the least significant 4 bits of the second operand, which would be 0, resulting in 1 << 0.