11-05-2005, 12:18 PM
This is an updated response as there was a missing rule in the last posting - it is highlighted in italic below.
i1 and uc have a different signedness and hence the expressions i1 | uc and i2 ? i1 : uc are not compliant with Rule 10.1.a. However the resultant underlying type can be deduced by extending the usual arithmetic conversion rules, as described in section 6.2.1.5 of ISO 9899:1990, to underlying types. They are described more fully at the end of this response.
&i1 and ip both have an underlying type of int *.
( i1 == i2 ) has a type of int, which is understood to be its underlying type. This is mentioned in 6.10.2 in the section on balancing conversions. There was discussion, whilst the guidelines were being drawn up, as to whether there should be an underlying type of Boolean, but it was felt that other rules sufficiently restricted the use of Boolean expressions
f has an underlying type of float.
Usual arithmetic conversion rules and underlying types
The existing rules in section 6.2.1.5 of ISO 9899:1990 apply to underlying types except the statements \"otherwise, both operands have type int\" can be replaced by
1. If both operands have the same underlying type, no further conversion is needed.
2. Otherwise if both operands have the same signedness, the operand with smaller magnitude is converted to the type of the other operand.
3. Otherwise if the operand with the larger magnitude is unsigned, the other operand is converted to the type of the larger magnitude type.
4. Otherwise, if the type of the operand with underlying signed type can represent all of the values of the type of the operand with underlying unsigned type, then the operand with unsigned type is converted to the type of the operand with signed type.
5. Otherwise, both operands are converted to the underlying unsigned type corresponding to the type of the operand with the underlying signed type.
\"signed char + unsigned int\" would then be caught by rule 3, which would convert \"signed char\" to \"unsigned int\".
i1 and uc have a different signedness and hence the expressions i1 | uc and i2 ? i1 : uc are not compliant with Rule 10.1.a. However the resultant underlying type can be deduced by extending the usual arithmetic conversion rules, as described in section 6.2.1.5 of ISO 9899:1990, to underlying types. They are described more fully at the end of this response.
&i1 and ip both have an underlying type of int *.
( i1 == i2 ) has a type of int, which is understood to be its underlying type. This is mentioned in 6.10.2 in the section on balancing conversions. There was discussion, whilst the guidelines were being drawn up, as to whether there should be an underlying type of Boolean, but it was felt that other rules sufficiently restricted the use of Boolean expressions
f has an underlying type of float.
Usual arithmetic conversion rules and underlying types
The existing rules in section 6.2.1.5 of ISO 9899:1990 apply to underlying types except the statements \"otherwise, both operands have type int\" can be replaced by
1. If both operands have the same underlying type, no further conversion is needed.
2. Otherwise if both operands have the same signedness, the operand with smaller magnitude is converted to the type of the other operand.
3. Otherwise if the operand with the larger magnitude is unsigned, the other operand is converted to the type of the larger magnitude type.
4. Otherwise, if the type of the operand with underlying signed type can represent all of the values of the type of the operand with underlying unsigned type, then the operand with unsigned type is converted to the type of the operand with signed type.
5. Otherwise, both operands are converted to the underlying unsigned type corresponding to the type of the operand with the underlying signed type.
\"signed char + unsigned int\" would then be caught by rule 3, which would convert \"signed char\" to \"unsigned int\".