Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > Paolo Carlini <[EMAIL PROTECTED]> writes: > > [...] > > | >Specifically, for PR 30465 "((T)1 << 31) - 1" is potentially undefined > | >when T is a 32-bit signed type, but well-defined if T is unsigned or > | >wider than 32-bits. > | > > | FYI: this specific issue arises from std::numeric_limits<wchar_t> on > | x86-linux: in particular from the __glibcxx_max macro at the beginning > | of the header. Luckily, since we are dealing with template > | specializations, the pragma is sufficient to suppress the warning, but > | if you can figure out a better way to compute the max itself, just > | speak... > > I would like to understand this issue better and AVOID the pragma. > If we need a pragma to make numeric_limits<wchar_t> not trigger > warning then something is broken in either the warning machinery or > numeric_limits<wchar_t> or both.
When T is a signed 32-bit type, the expression ((T)1 << 31) is undefined. This is very clear in C99, section 6.5.7 (here I'm assuming that C++ is similar): 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. 1 × 2^31 is not representatable in a 32-bit signed type. The largest number that can be represented in a 32-bit signed type is, of course, 1 × 2^31 - 1. That is the number the above expression is trying to compute, but operator precedence means that the actual result is undefined. One way to write this expression in a fully defined manner is: (((((T)1 << 30) - 1) << 1) + 1) Another way is: ((T)(((unsigned T)1 << 31) - 1)) Ian