Underlying Type Presumptions

[gs]

I have made some presumptions regarding the MISRA 2004 concept of Underlying Type. Do correct me if I am wrong in these presumptions.

1. Explicit casts change an expression's underlying type
2. The Standard is not concerned with an expression's underlying type if any of its sub-expressions violate a required underlying type-related rule
3. Implicitly converting an expression (excluding promotions) change its underlying type
4. Effectively Boolean expressions have underlying type of int (see commentary in MISRA 2004, 6.10.2)
5. Enums and enumerations constants have underlying type of int (see C90 Standard, Clause 3, Section 1, Sub-section 3, Part 3)

Does anyone see a problem with any of these?

[MISRA Reply]

1. Explicit casts can change the underlying type of their enclosing expression. For example using the types and names in 10.2:

Code:

s32a = s16a + (int32_t)s16b;

is compliant. Without the explicit cast the + expression would have an underlying type of int16_t, but with the explicit cast the underlying type is int32_t. The underlying type of s16b is not altered, but the underlying type of (int32_t)s16b is int32_t.

2. It is correct that the guidelines is not concerned with an expression’s underlying type if any of its sub-expressions violate an underlying type-related rule. However the resultant underlying type can be deduced by extending the usual arithmetic conversion rules, as described in section 6.2.1.5 of ISO 9899:1990, to underlying types.

3. In the example for question 1 there is an implicit conversion on s16a from int16_t to int32_t. The underlying type of s16a it-self is not altered, but the underlying type of the left hand expression to + after the implicit cast is int32_t.

4. It is correct that effectively Boolean expressions have underlying type of int. There was discussion, whilst the guidelines were being drawn up, as to whether there should be an underlying type of Boolean, but it was felt that other rules sufficiently restricted the use of Boolean expressions

5. The MISRA C guidelines treat objects of type enum as having an underlying type of int. Enumeration constants follow the same rules as other integer constants. In other words their underlying type is a function of their magnitude. See 6.10.4 in the MISRA C guidelines.

There was much discussion whilst the guidelines was being written as to whether enumerated types should be forced to be strongly typed. It was felt that in an ideal world no integral operations would be allowed on enumerated constants. However it was decided in the end not to add such rules to MISRA-C:2004.

[Achim Olaf Zacher]

If „effectively Boolean expressions have underlying type of int“ (implicit signed int without u?) this potentially conflicts with rule 6.4 and 10.1? It’s no longer possible to have a single bit flag or semaphore (TRUE/FALSE) in a bit field? Is this intended or did I misunderstand this?

[misra-c]

Good point!

It was not intended that the use of 1 bit bitfields to store TRUE/FALSE should be banned.

Rules 10.1 and 10.3 were designed with signed and unsigned expressions in mind. The treatment of enums, bitfields, chars, relational operators ( < , , >= ), logical operators ( &&, || ) and equality operators ( ==, != ) do not fit this model as yet.

Clarifications are under consideration to address this.

Paragraph 4 and paragraph 5 above are withdrawn.

Provisional position:

The underlying type of the result of a logical operator is considered to be 1-bit, i.e. Boolean.