Someone was talking with me about wraparound in C (0xffff + 0x0001 = 0x0000), and it led me to the following situation:
int main() {
unsigned int a;
for (a = 0; a > -1; a++)
printf("%d\n", a);
return 0;
}
Compiling with GCC, this program exits without running the loop, which I assume is because -1
was implicitly cast to 0xffff
. The same happens when switching int
to long
. However, when switching to char
, the program runs indefinitely. I would expect that since the int
did not run the loop, neither would the char
. Can someone explain what sort of implicit casting the compiler is performing in this situation, and is it defined in one of the editions of the C standard or is it compiler-dependent?
In C, unsignedness is sticky:
unsigned int a;
/* ... */
a > -1
in the above >
expression, the left operands is of type unsigned int
and the right operand is of type int
. The C usual arithmetic conversions convert the two operands to a common type: unsigned int
and so the >
expression above is equivalent to:
a > (unsigned int) -1
The conversion of -1
to unsigned int
makes the resulting value a huge unsigned int
value and as a
initial value is 0
, the expression is evaluated to false (0
).
Now if a
is of type char
or int
, -1
is then not converted to unsigned int
and so 0 > -1
is true (1
) as expected.
Quote excerpted from ISO/IEC 9899:
If both of the operands have arithmetic type, the usual arithmetic conversions are performed.
Several operators convert operand values from one type to another automatically.
Many operators that expect operands of arithmetic type cause conversions and yield result types in a similar way. The purpose is to determine a common real type for the operands and result. For the specified operands, each operand is converted, without change of type domain, to a type whose corresponding real type is the common real type. Unless explicitly stated otherwise, the common real type is also the corresponding real type of the result, whose type domain is the type domain of the operands if they are the same, and complex otherwise. This pattern is called the usual arithmetic conversions:
First, if the corresponding real type of either operand is long double(...)
Otherwise, if the corresponding real type of either operand is double(...)
Otherwise, if the corresponding real type of either operand is float(...)
Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:
If both operands have the same type, then no further conversion is needed.
Otherwise, if both operands have signed integer types or both have unsigned integer types(...)
Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.
Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type.
Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With