Constant Size and Rule 12.2

Moderators: misra-c, david ward

Post Reply
mjlinden
Posts: 2
Joined: Fri Jan 17, 2014 1:33 pm
Company: Magnetrol International

Constant Size and Rule 12.2

Post by mjlinden » Mon Jan 20, 2014 2:33 pm

Hi Folks,

I'm trying to come to an understanding of an issue associated with MISRA 2012 Rule 12.2 and the interpretation of constant size. Here is the situation I'm dealing with.

=====================================================================
int32_t result;

result = (1<<15);

PC-lint Message:
|
result = (1<<15);
Common\TimeFlight.c(1572) : Note 9053: the shift value is at least the precision of the essential type of the left hand side [MISRA 2012 Rule 12.2, required]
Common\TimeFlight.c(1572) : Note 9031: Composite expression assigned to a wider essential type [MISRA 2012 Rule 10.6, required]
======================================================================

The above messages were generated for a 32-bit environment in which PC-lint is configured for a 32-bit "int".

I discussed the Rule 12.2 message with Gimpel (the PC-lint folks) who replied as follows, "According to the MISRA C 2012 guidelines, the essential type of an integer constant is, if it can be represented as an int, the signed type of lowest rank. In this case, that type is signed char, resulting in the message." While I was not able to find the underlined text in the MISRA 2012 standard, it may be otherwise stated. If this is the case, it is inconsistent with my long time belief that the lowest rank that an integer constant can have (without a suffix or cast) is type int. Can you explain the rationale behind this?

Thanks, Michael

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

Re: Constant Size and Rule 12.2

Post by misra-c » Mon Feb 10, 2014 2:15 pm

In replying to this question it is necessary to understand the distinction between the standard types as described in the C standard and essential types as described in the MISRA C:2012 guidelines. The rationale and description of the MISRA essential types can be found in section 8.10 and Appendices C and D of the MISRA C:2012 guidelines.

You are correct in saying that the smallest C standard type for an integer constant with no suffix is "signed int". However, the essential type is the type with lowest rank that can represent the value. This is defined in Appendix D.3. In the above example this means that "1" has an essential type of "essentially signed char". And hence 15 would exceed the maximum value of 7 that is permitted for shifting an "essentially signed char".

The MISRA essential types model produces a internally consistent view of C types, but a side-effect of keeping the model simple has been that a few integer constant expressions may violate some MISRA guidelines. Your example is one of those occasions and is similar to that given in the example section of rule 12.2 where "1u<<10u" is non-compliant for the same reason. A similar work round for your example would be "result = (int32_t)1 << 15;"

It should also be noted that the example violates rule 10.1 as the left-hand side of the shift operator has an "essentially signed type". The result of the shift operation on an "essentially signed type" is defined in Appendix D.7 as being the C standard type, which in this case would be a "signed integer". This means that there is no violation of rule 10.6 on the assignment.
---
Posted by and on behalf of
the MISRA C Working Group

mjlinden
Posts: 2
Joined: Fri Jan 17, 2014 1:33 pm
Company: Magnetrol International

Re: Constant Size and Rule 12.2

Post by mjlinden » Wed Feb 12, 2014 5:37 pm

Thanks for your response...

-Michael

hhallen
Posts: 1
Joined: Fri Oct 08, 2010 10:22 am
Company: Autoliv

Re: Constant Size and Rule 12.2

Post by hhallen » Thu May 26, 2016 5:47 pm

I have recently had a dialogue with the support at Programming Research, since we use their QA-C static analysis tool with the MISRA-C:2012 add-on. My example:

extern unsigned int getShift(void);
const unsigned int shift = getShift();
const unsigned int multiplier = 1u << shift;

The last line in this example incurs three warnings:
4491: A composite expression of 'essentially unsigned' type (%1s) is being converted to wider unsigned type, '%2s' on assignment.
4499: An expression which is the result of a ~ or << operation has been converted to a wider essential type on assignment.
4571: The left-hand operand of this << operator has an 'essential type' which is narrower than type 'int'.

In the context of all compliant C99 compilers, these three warnings are all nonsense.
4491: Wrong, the expression is of the type unsigned int. Even if the constant 1u were of a type with lesser rank (which it is not), it would be promoted to unsigned int through C99's standard integer promotions, and so in any case the entire expression is computed on unsigned int operands and produces an unsigned int result.
4499: Same thing.
4571: True in the context of MISRA's fictitious 'essential type' system, but false in all compliant C99 compilers.

Programming Research gave me essentially the same explanation as misra-c has done in this thread, based on MISRA's 'essential type' system. I can see how a tools provider would have to follow the MISRA standard, and I accept that QA-C has to emit these warnings. But they are not helpful; on the contrary, they create confusion and erodes the confidence a developer should have in his static analysis tool.

I would like to add that the most harmful property in the 'essential type' system is what it says about the essential type of expressions, for example in appendix D.7, the section about the shift operators:
1. If the left hand operand is essentially unsigned then:
1.1 If both operands are integer constant expressions then the essential type of the result is the UTLR of the result.
1.2 Else the essential type of the result is the essential type of the left hand operand.

This describes a behavior that no actual compiler (at least no compliant C99 compiler) would ever exhibit. Other places in the MISRA-C:2012 standard puts emphasis on adhering to the C standard (whether C90 or C99), and rightly so. But to me it seems that this 'essential type' system means that the MISRA standard itself deviates from the C standard. I sincerely hope that this is tossed overboard in the next iteration of MISRA-C.

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

Re: Constant Size and Rule 12.2

Post by misra-c » Fri Sep 23, 2016 8:59 am

Thank you for your feedback. The essential type system is designed to be stricter than the standard C type system. The messages are consistent with the MISRA-C guidelines.

It is inappropriate for us to comment on the output of individual tools.
---
Posted by and on behalf of
the MISRA C Working Group

Post Reply

Return to “8.7 Literals and constants”