Essential type of integer constant expression of rank greater than unsigned int; interaction with addition to char

Moderators: misra-c, david ward

abgs
Posts: 12
Joined: Wed Sep 06, 2017 4:25 pm
Company: Gimpel Software

Essential type of integer constant expression of rank greater than unsigned int; interaction with addition to char

Section D.6 says "If the standard type of an integer constant is unsigned int then its essential type is the UTLR." Then:

- The essential type of the integer literal 5U is unsigned char because the standard type is unsigned int and unsigned char is the smallest unsigned type capable of representing the value 5.

- The essential type of the integer literal 5UL is unsigned long because the standard type of the integer constant is not unsigned int and so the rule under the heading "Integer constants" has no effect.

Section D.7 describes the essential type of "Operations subject to the usual arithmetic conversions". Specifically, it says that "if the operands are both essentially unsigned then ... If the expression is an integer constant expression then the essential type of the result is the UTLR of the result", where "UTLR" is defined in D.3 as "the unsigned type having the lowest rank required to represent the value of a particular integer constant expression or the maximum value of a bit-field." Note in particular the absence of any restriction based on the standard type, unlike in the rule for literals. Then:

- The essential type of the integer constant expression 5U*5U is unsigned char because it is the unsigned type of lowest rank capable of representing the value 25.

- The essential type of the integer constant expression 5UL*5UL is also unsigned char because it is the unsigned type of lowest rank capable of representing the value 25.

The last conclusion regarding 5UL*5UL is complicated by the seemingly contradictory observation made in D.1 that "The essential type of an expression only differs from the standard C type (standard type) in expressions where the standard type is either signed int or unsigned int." while the standard type of this expression is unsigned long. If this passive statement is taken as a restriction on all other rules determining essential type (despite this not being stated) then there would be several strange effects:

- The essential type of the integer constant expression (uint32_t)(5U*5U) would differ depending on whether the typedef uint32_t is defined as "unsigned int" or "unsigned long", even if both are unsigned 32-bit integer types.

- The rules for the essential type of a bit-field in D.4 would no longer apply to bit-fields of type "unsigned long" if supported by the implementation, despite being explicitly permitted by rule 6.1.

- The explicit restriction that the essential type of an integer constant of unsigned type is only the UTLR when standard type is unsigned int in D.6 would be redundant.

- The essential type of the expression 'c'+1UL is specified to be char in D.2, but the standard type is not int nor unsigned int.

So my questions are:

- Is the essential type of 5U unsigned char?
- Is the essential type of 5UL unsigned long?
- Is the essential type of 5U*5U unsigned char?
- Is the essential type of 5UL*5UL unsigned char or unsigned long?
- Does the essential type of (uint32_t)(5U*5U) depend on whether uint32_t is defined as unsigned int or unsigned long if both are 32-bit unsigned integer types?
- Is the essential type of an expression referring to the value of a bit-field implemented using unsigned long in a C99 compiler that allows this the UTLR for the maximum value of the bitfield, or unsigned long?
- Is this sentence in D.1 intended to have any normative effect, and if so what is it and what is its scope? "The essential type of an expression only differs from the standard C type (standard type) in expressions where the standard type is either signed int or unsigned int."
- If the preceding phrase from D.1 does have a normative effect, is the reference to the specific standard type rather than merely the signedness in the phrase "If the standard type of an integer constant is unsigned int" in D.6 redundant?
- Is the essential type of the expression 'c'+1UL char as stated in D.2, or unsigned long if essential types cannot differ from standard types when the standard type is not signed/unsigned int as noted in D.1?

abgs
Posts: 12
Joined: Wed Sep 06, 2017 4:25 pm
Company: Gimpel Software

Re: Essential type of integer constant expression of rank greater than unsigned int; interaction with addition to char

Rule 10.2 also seems to be at odds with D.1:
For the + operator, one operand shall have essentially character type and the other shall have essentially signed type or essentially unsigned type. The result of the operation has essentially character type.
Is it intended that "shall have essentially signed type or essentially unsigned type" allows char + long etc.?

abgs
Posts: 12
Joined: Wed Sep 06, 2017 4:25 pm
Company: Gimpel Software

Re: Essential type of integer constant expression of rank greater than unsigned int; interaction with addition to char

Correction in original post: replace (uint32_t)(5U*5U) with (uint32_t)5U * 5U. The essential type of the original example is not actually based on the UTLR in the first place. The standard type of this new expression will still vary from unsigned int to unsigned long but the essential type should now vary between unsigned long and unsigned char depending on the definition of uint32_t as the example originally intended because the top level binary operator uses the UTLR.

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

Re: Essential type of integer constant expression of rank greater than unsigned int; interaction with addition to char

The intention of the document is that the following statement in D.1 is just a comment and that it is the result of applying the subsequent sections in Appendix D.
The essential type of an expression only differs from the standard C type
in expressions where the standard type is either signed int or unsigned int
The MISRA working group agree that various wordings in Appendix D is unclear. This will be clarified in a future TC. In the interim, your examples should be interpreted as follows:

- Is the essential type of 5U unsigned char?
The unsigned type of lowest rank(UTLR) in which 5 fits, which is "unsigned char".

- Is the essential type of 5UL unsigned long?
The C Standard type has a rank greater than int, so the essential type is "unsigned long".

- Is the essential type of 5U*5U unsigned char?
The unsigned type of lowest rank(UTLR) in which 25 fits, which is "unsigned char".

- Is the essential type of 5UL*5UL unsigned char or unsigned long?
The resulting essential type will be "unsigned long", which is the C standard type for the expression.

- Does the essential type of (uint32_t)5U * 5U depend on whether uint32_t is defined as unsigned int or unsigned long if both are 32-bit unsigned integer types?
The C standard type of the expression will be "unsigned int" or "unsigned long" depending on the definition.
If uint32_t is "unsigned int", the essential type will be "unsigned char" as the UTLR is determined by the value of the result which is 25.
If uint32_t is "unsigned long", the C standard type of the expression is "unsigned long" resulting in an essential type of "unsigned long".

- Is the essential type of an expression referring to the value of a bit-field implemented using unsigned long in a C99 compiler that allows this the UTLR for the maximum value of the bitfield, or unsigned long?
The use of unsigned long is implementation defined in C99. The MISRA working group is still considering this.

- Is this sentence in D.1 intended to have any normative effect, and if so what is it and what is its scope?
See discussion at start of the response

- Is the essential type of the expression 'c'+1UL char as stated in D.2, or unsigned long if essential types cannot differ from standard types when the standard type is not signed/unsigned int as noted in D.1?
The intention was that the essential type would be "unsigned long".

- Rule 10.2 Is it intended that "shall have essentially signed type or essentially unsigned type" allows char + long etc.?
The intention was for rule 10.2 not to permit "char + long".
---
Posted by and on behalf of
the MISRA C Working Group