Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Is rule 10.5 compliant with rule 10.3?
#1
Rule 10.3 requires a \"complex expression\" of integer type only be explicitly cast to a NARROWER type.

Rule 10.5 requires that bitwise operator RESULT be immediately cast to the underlying type (NOT a NARROWER type).

Based on the discussion in 6.10.5, a shift-expression IS considered a \"complex expression\" such that rule 10.3 should apply to rule 10.5? If so, doesn't this cast back to the underlying type violate rule 10.3?

The primary motivation of this question is that I think rule 10.3 should prohibit an explicit cast to a WIDER type, rather than only allow a cast to a NARROWER type. This seems to fit better with 6.10.3's discussion under \"evaluation type confusion\" (p. 38), as well as 6.10.1's \"to change the type in which subsequent arithmetic operation is performed\" statement.

It might be preferred that an expression use the implicit conversion rather than explicitly casting to the underlying type -- but should explicitly casting to the underlying type be prohibited by rule 10.3? Sometimes, the cast to the underlying type may be the same as the actual (promoted) type of the expression, and other times the cast to the underlying type is a conversion of the promoted type back to the underlying type. This depends on the types and the implementation-defined sizeof(int).

Some examples:

(1) Should:
[code]U16 = (uint16_t)((uint16_t)U8


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)