Welcome to the MISRA discussion forum

why are the following expressions are compliant/not compliant

u8a = 5U - compliant(u8a=u16b - not compliant at the same time)
u8a = 5UL not compliant

it is not a conversion to a wider integer type of the same signedness as in 10.1 a)
It is more an implicit conversion from wider to narrower types.
And why in one case it is compliant, and in another one not compliant.

1.The expression

u16a = u16b + u16c yields a u16 bit result if int is 16 bits, this means that
u16a = u16b + u16c is compliant on a 16-bit machine.

but
u16a = u16b + u16c yields a signed 32 bit result on a 32-bit machine, so explicit type case has to be used to make the result compliant?
u16a =(u16)(u16b + u16c )

but this is not MISRA comform(rule 10.3 says type has to be narrower as the underlying type)

what is the solution for the expression u16a = u16b + u16c to be MISRA -conform on both machines?(will u16a = (u16)u16b + (u16)u16c also result in integral promotion?)

2. int16_t foo1(uint8_t x)
{
return(20000) compliant on the 16 bit machine
return(20000) not compliant on the 32 bit machine
}

right? (this is from example to rules 10.1-10.2 return(20000))

The MISRA II documentation states the following is compliant with the requirements of rule 19.4:

#define A 8
#define B A

However, it does not specifiy whether the following is also compliant:

#define B A
#define A 8

In the latter case, B does ultimately expand to 8, a constant, adhering to rule 19.4. However, at the time of #definition, B does not expand to a constant, braced initializer, parenthesized expression, type qualifier, storage class specifier or do-while-zero construct. Only after processing the #definition for A, is compliance certain (future re-#definition notwithstanding). My question: at what code processing point, does MISRA II, Rul 19.4, require the macro to evaluate to the prescribed formats? At the end of all preprocessing? At #definition time? Sometime else?

The rules 17.1 to 17.3 give some possibilities to manipulate pointers (arithmetic, substraction, comparison) whereas the rule 17.4 doesn't authorize pointer manipulation in any way other than array indexing.

Should it be possible to explain me where I make a mistake in my understanding?

In particular, I would like to know if the following code is MISRA 2004 compliant concerning pointer manipulation:

Rule 10.5: result of ~ and

I know this should have been brought up before, but in reviewing MISRA-2 this passed me by.
Being pedantic, why has the rule on break (14.6) been relaxed and not 14.5 (or 14.4)?
A break in a loop is just a goto!
I have no problem with it, it just smacks of inconsistency.

Question: What is the essential requirement of Rule 13.3 ?

Rule 13.3 only prohibits the use of == and !=.

Does this mean that it is legitimate to use the >= and 10.0f ) /* compliant */
…
if ( speed = (10.0f – tolerance)) && ( speed

Question: What is the character set referred to in Rule 3.2?

Answer: MISRA C Steering Team

There are two character sets.
The source code is written in one character set.
The program can execute with input/output in a second character set.
These may or may not be the same.
Both the basic source character set and the basic execution character sets shall be documented.
This rule allows free choice of character sets for coding and execution. This use shall be documented.

Question: Is Rule 20.1 applicable to \"defined\"?

(a) We presume that \"#define defined (10)\" will be in violation of Rule 20.1.

(b) If our presumption is correct, then which of \"reserved identifier\", \" macro\" or \"function\" will \"defined\" be?
We could not find the answer in ISO/IEC 9899:1990. Is it described somewhere in COR1, COR2 or AMD1?

Answer: MISRA C Steering Team 7/9/2005

(a) YES - defined is included in the text under the rule.

(b) defined is listed under 6.8.8 Predefined Macro Names.
It is also listed in Appendix G: Undefined Behaviour 54.