Is rule 10.5 compliant with rule 10.3?

[rmgalles]

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

[Gavin McCall]

The MISRA-C team will review this issue 27-28/2/2006.

[Shane Swenson]

Has the MISRA-C team reached a resolution for this question?

[misra-c]

MISRA-C meeting 23-8-2006

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 to be immediately cast to the underlying type (NOT a NARROWER type).

We agree that this is a contradiction.

10.5 should be treated as an exception to 10.3.

We are further considering this issue, since an alternative is to modify 10.3 to allow explicit casts to the same size or narrower. This has greater implications on allowing “redundant” casts, and requires further consideration.