+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA C:2012 and MISRA C:2023 guidelines (https://forum.misra.org.uk/forumdisplay.php?fid=21)
+---- Forum: 8.10 The essential type model (https://forum.misra.org.uk/forumdisplay.php?fid=165)
+---- Thread: 10.1 the calculation "50 << 3U" looks safe to me (/showthread.php?tid=1424)
10.1 the calculation "50 << 3U" looks safe to me - danielmarjamaki - 22-05-2018
In the description for 10.1 is is said that the calculation "50
Re: 10.1 the calculation "50 << 3U" looks safe to me - danielmarjamaki - 23-05-2018
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.
Re: 10.1 the calculation "50 << 3U" looks safe to me - Francois - 28-05-2018
Hi
To me, "50
Re: 10.1 the calculation "50 << 3U" looks safe to me - danielmarjamaki - 29-05-2018
Thank you for the reply.
Your answer does not make sense to me. The result of "50
Re: 10.1 the calculation "50 << 3U" looks safe to me - danielmarjamaki - 29-05-2018
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
Re: 10.1 the calculation "50 << 3U" looks safe to me - misra-c - 08-06-2018
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
Quote: 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.
RE: 10.1 the calculation "50 << 3U" looks safe to me - misra-c - 02-07-2024
MISRA C:2012 TC2 added reference to the undefined behaviour to Rationale 6