3 ms·

A correction: a compiler would not be able to assume that `x` is always positive because casts between signed and unsigned integer types are based on their bina

A correction: a compiler would not be able to assume that `x` is always positive because casts between signed and unsigned integer types are based on their binary representation (what computers see), not their value (what humans see).[1] [1] https://wandbox.org/permlink/dDDAJjOlm50GD1PW https://wandbox.org/permlink/dDDAJjOlm50GD1PW It would be able to (correctly) make that assumption if `x` were a long, assuming 64-bit longs and 32-bit int/unsigneds.

int_19h 9y ago
In the C standard, a cast from unsigned to signed integer is undefined behavior if it overflows. So the compiler can, indeed, assume that "x" is always positive in the code snippet above - if the value of "u" is such that it would require signed wraparound when initializing "x", the rest of the program is U.B., and so that possibility doesn't even have to be considered.
- smitherfield 9y ago
  This is untrue; see section 6.3.1.3: When a value with integer type is converted to another integer type ... [if] the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised. http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf So casts from unsigned to signed must have a well-defined result, but the implementation can choose how to define it. You could in theory have an implementation that defines that casts from unsigned to signed are always positive,[1] but since that's not how GCC and every other mainstream (existing?) compiler defines it, they are not allowed to assume the result of a cast from an arbitrary unsigned integer to a signed integer of equal width is positive. [1] In which case the compiler would be allowed to assume that unsigned-to-signed casts are never negative. This assumption would however be both safe and correct, and would have nothing to do with UB.

int_19h 9y ago

In the C standard, a cast from unsigned to signed integer is undefined behavior if it overflows. So the compiler can, indeed, assume that "x" is always positive in the code snippet above - if the value of "u" is such that it would require signed wraparound when initializing "x", the rest of the program is U.B., and so that possibility doesn't even have to be considered.

smitherfield 9y ago
This is untrue; see section 6.3.1.3: When a value with integer type is converted to another integer type ... [if] the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised. http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf So casts from unsigned to signed must have a well-defined result, but the implementation can choose how to define it. You could in theory have an implementation that defines that casts from unsigned to signed are always positive,[1] but since that's not how GCC and every other mainstream (existing?) compiler defines it, they are not allowed to assume the result of a cast from an arbitrary unsigned integer to a signed integer of equal width is positive. [1] In which case the compiler would be allowed to assume that unsigned-to-signed casts are never negative. This assumption would however be both safe and correct, and would have nothing to do with UB.