10.1 the calculation "50 << 3U" looks safe to me

[danielmarjamaki]

In the description for 10.1 is is said that the calculation "50

[danielmarjamaki]

as I read the MISRA PDF, the motivation that this is not compliant is that the result is "implementation defined".

According to the C99 standard.. In a bitshift; if the result can be represented in the result type then it is well-defined behaviour. If the result can't be represented in the result type then it is undefined behaviour. I see nothing about "implementation defined" behaviour.

[Francois]

Hi
To me, "50

[danielmarjamaki]

Thank you for the reply.

Your answer does not make sense to me. The result of "50

[danielmarjamaki]

Thank you for the reply. However it does not make sense to me. The result will be a signed integer with the value 400. Therefore there is still a sign bit.

It seems you confuse the type rules. For most other binary operators the result type depends on both operand types. For instance, as you know, if you have "50 + 3U" then the result is unsigned. But the result type of > is the promoted LHS type so the "50

[misra-c]

Rule 10.1 knowingly includes violations on code that is well-defined. This is to enable a rule to be produced that is simple to understand and to check. Your particular example is well-defined in producing a result, but there are two ways in general that a shift on an expression with a signed type may fail.

In section 6.5.7 on the C99 Standard

4 ... If E1 has a signed type and nonnegative value, and E1x2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.

5 ... If E1 has a signed type and a negative value, the resulting value is implementation-defined.

You are correct to highlight that rationale 6 only mentions implementation-defined behaviour. It should also mention the undefined behaviour given above.

[misra-c]

MISRA C:2012 TC2 added reference to the undefined behaviour to Rationale 6