Welcome to the MISRA discussion forum

From "Underlying type balancing" on page 57:

Quote:Otherwise, if both operands have integral type, the underlying type of the expression can be found using the following:
– If the types of the operands are the same size, and either is unsigned, the result is unsigned.
– Otherwise, the type of the result is that of the larger type.

I feel, the sentence "The use of digraphs may not meet developer expectations." is not clear.
The usage of digraphs are only system constraints.
Digraph are just an alternative method for a systems that can not input '{','}','[',']'.
Therefore, there is no point in leaving a digraph in the final source file.
Even if anyone use a system that requires digraphs, it is better to replace in the final source file from digraph(alternative token) to primary token.

Consider:

namespace {
typedef unsigned short ui16;
const ui16 x = 1U;
const ui16 y = 2U;
const ui16 z = x + y;
}

Page 55 of MISRA C++ states:

"The underlying type of an integer constant expression is therefore defined as follows: 1. If the actual type of the expression is signed integral, the underlying type is defined as the smallest signed integer type that is capable of representing its value."

* The actual type of x + y is int
* The value of x + y is three
* The smallest signed type capable of representing three is signed char
* The underlying type of x + y is signed char

This also seems to match the behavior on page 60:

"The underlying type for a constant expression “e” with a value “v” will have the same signedness as “e”, and a magnitude given by the underlying type of a single integer-literal with the same value as “v”." (referring to page 58 "The underlying type of an integral literal is the smallest fundamental type of the appropriate sign required to store its value.")

where:

* "e" is x + y
* The actual type of "e" is int (determining signedness)
* "v" is three
* The underlying type of an integer literal with the value three is signed char (determining magnitude)
* The underlying type of x + y is signed char

Is this interpretation correct?

Hello everyone,
as stated in: https://www.misra.org.uk/forum/viewtopic...2334#p2334 official answers (i suspected and hope only via the misra-c account) have normative power. This decision is impractical (for me), as we will have to set up a task to perform an check regularly if the standard has been corrected or otherwise updated via an answer; but this can be done. I would like you to ask however 2 favors:

1) As the above linked answer was in the MISRA-C:2004 sub-forum, can you please point out and confirm the normative power for the whole of the MISRA-C discussions at a prominent place?

2) As consistency and completeness is quite hard to obtain just by studying the comments, could you please systematically add additional information for each of the misra-c user answers,
- if they contain normative content (not all do!) or not,
- if the normative content is (still) valid or deprecated
- if the normative content is deprecated, by what it was invalidated (e.g. a other comment, a MISRA-C TC, new edition...)

With regards,
Mark Alexander

Dear community,

our analysis tool reports the following struct initialization to violate rule 11.9 (macro NULL is the only permitted form of integer null pointer constant):

static const myType myStruct = {
64,
{0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0},
0
};

with:
typedef unsigned short uint16;
typedef unsigned char uint8;
typedef struct {
uint16 myVariable01;
uint8 myArray [16];
uint8 myVariable02;
} myType;

Unfortunately, neither from the tool documentation nor from the MISRA documentation we can conclude why this initialization would be non-compliant. Also we cannot see what the risk behind this deviation would be. Is this deviation false-positive? Does it introduce any portability, maintainability etc. risk?

Thanks for your support.
Frank

Dear community,

our analysis tool reports the following array initialization to violate rule 11.9 (macro NULL is the only permitted form of integer null pointer constant):

uint8 myBuffer[8] = {0u}; // with "typedef unsigned char uint8;"

Unfortunately, neither from the tool documentation nor from the MISRA documentation we can conclude why this "standard" construct would be non-compliant. Also we cannot see what the risk behind this deviation would be. Is this deviation false-positive? Does it introduce any portability, maintainability etc. risk?

Thanks for your support.
Frank

In Appendix D.1 the following limitation for the paragraphs D.n:

Quote:The essential type of an expression only differs from the standard C type (standard type) in expressions where the standard type is either signed or unsigned int.

Quote:1. If the operands are both essentially signed then
[...]
2. Else if the operands are both essentially unsigned then
[...]
3. Else the essential types are the standard type

Quote:"2. Else if the operands are both essentially unsigned"
"2.1 If the expression is an integer constant expression the essential type of the result is the UTLR of the result."

Hi,

Quick question about rule 13.2:
the following variable:

const volatile uint8_t myvar = 0;

should it be considered as volatile or non-volatile in the context of rule 13.2 ?

thank you.

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?

The description of cvalue expressions in section 6 uses the phrase "constant integral expressions" while citing the C++ standard section on constant expressions which does not contain the quoted phrase. Is "constant integral expressions" intended to say "integral constant expression", or does "constant integral expression" refer to a distinct concept?

Below, under the heading "Constant expressions", rules for "a constant expression" are defined in terms of the value of an integer literal. Not all "constant expressions" are integer values, e.g. the address-of operator can produce a "constant expression" of pointer type (but is not an "integral constant expression"), and it does not make sense to speak an integer literal having a pointer value. Is the use of unqualified "constant expression" here intended to have some missing "integral" qualification, or to continue referring to the "constant integral expressions" used earlier?

"Constant expressions" involving floating point arithmetic are not considered "integral constant expressions" but are "arithmetic constant expressions" (whereas "integral constant expressions" may contain floating literals if they are immediately cast to an integer type). Is an "arithmetic constant expression" that is not an "integral constant expression" considered a "constant integral expression" for the purposes of determining whether an expression is or is not a cvalue? Is an "arithmetic constant expression" considered a "constant expression" [presumably with a missing "integral" somewhere"] for the purposes of the "Constant expressions" heading even though it is not an "integral constant expression"?