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

Moderators: misra-c, david ward

Post Reply
danielmarjamaki
Posts: 7
Joined: Sun Apr 09, 2017 1:14 pm
Company: Evidente

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

Post by danielmarjamaki » Tue May 22, 2018 2:38 pm

In the description for 10.1 is is said that the calculation "50 << 3U" is non compliant. That calculation looks safe to me. The result is 400 if I calculate correctly in my head.

danielmarjamaki
Posts: 7
Joined: Sun Apr 09, 2017 1:14 pm
Company: Evidente

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

Post by danielmarjamaki » Wed May 23, 2018 9:47 am

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
Posts: 9
Joined: Thu Jul 13, 2017 2:22 pm
Company: TE CONNECTIVITY

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

Post by Francois » Mon May 28, 2018 7:26 am

Hi
To me, "50 << 3U" is non compliant because of the essential type of 50.
It is a signed integer.
a shift operation on signed integer is not permeted because the value of the sign bit will be lost.
You should use an unsigned container (explicit cast or other variable).

danielmarjamaki
Posts: 7
Joined: Sun Apr 09, 2017 1:14 pm
Company: Evidente

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

Post by danielmarjamaki » Tue May 29, 2018 6:00 am

Thank you for the reply.

Your answer does not make sense to me. The result of "50 << 3U" still has a sign bit so it is not lost.

danielmarjamaki
Posts: 7
Joined: Sun Apr 09, 2017 1:14 pm
Company: Evidente

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

Post by danielmarjamaki » Tue May 29, 2018 6:22 am

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 << and >> is the promoted LHS type so the "50 << 3U" result is a signed integer.

misra-c
Posts: 566
Joined: Thu Jan 05, 2006 1:11 pm

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

Post by misra-c » Fri Jun 08, 2018 8:38 am

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.
---
Posted by and on behalf of
the MISRA C Working Group

Post Reply

Return to “8.10 The essential type model”