6.3.1.8p1: 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, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank. 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.
For the bolded rule to be applied it would seem to imply you need to have have an unsigned integer type who's rank is less than the signed integer type and the signed integer type cannot hold all the values of the unsigned integer type.
Is there a real world example of such a case or is this statement serving as a catch-all to cover all possible permutations?
If you had a platform where sizeof(long int)==sizeof(int)
, then signed long int
and unsigned int
would fall into this rule. In any case, the standard does not dictate that conversion rank is equivalent to size, only that conversion rank provides an ordering that is a valid ordering on size (6.3.1.1.p1.1 (sp?)):
No two signed integer types shall have the same rank, even if they have the same representation.
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