Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Underlying Types
#2
** This response has been superseded - see 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 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.
4. Otherwise, both operands are converted to the underlying unsigned type corresponding to the type of the operand with the underlying signed type.


Messages In This Thread

Forum Jump:


Users browsing this thread: 4 Guest(s)