Welcome to the MISRA discussion forum

There are no boolean types in C and I assume that rule 10.x also apply to boolean expressions. The question now is how to make
boolean expressions compliant to these rules.
If there are variables boolU8 and boolS8 which are of type unsigned char and signed char are represent boolean values, and assignment
will require an explicit cast:
boolU8 = (uint8)boolS8;
No problem here.

Boolean operators &&, || and ! yield a result of type "int" (MISRA-C:2004 page 37 3rd paragraph), which confuses me a little bit,
because I expected the guideline to specify an "underlying type" instead of a real type.
So to have a simple assignment like
boolU8 = c && d;
compliant, I have to downcast to the result to uint8, which requires a temporary variable (according to rule 10.3):
int _t = c && d;
boolU8 = (uint8)_t;

The is no more safe than the simple assignment, a lot less readable and involves the plain type "int", which violates rule 6.3 (typedefs
should be used in place of the basic types).

I did not find anything on this subject in the technical corrigendum, nor does the entry in the glossary on "boolean expressions" help
with type casting.

Any thoughts ?

I need to provide an objective evidence showing that Software safety is improved by compliance to MISRA-C rules. The provided evidence should include quantitative measurements that show safety improvement after the application of MISRA-C rules. Please help.

In C, there are three types of characters: "char", "signed char", and "unsigned char". (The representation of the type "char" is either signed or unsigned). Note that this makes characters different than the other integer types as, for example, "short" is a synonym for "signed short".

Rule 10.5 states "if the bitwise operators ~ and

Hi Board,

exist any relation/ raccamandation in IEC 26262 to follow the new MISRA AC rules ?

Thanks Giacomo

The description of rule 10.5 mentions that the operators must be applied to "small integer types" for the casts to be required. The types unsigned char and unsigned short are mentioned explicitly. What if char, short, and int are all the same size on the machine? In that case is OK to not perform the required cast? This really comes down to whether or not we should be checking for the unsigned char and unsigned short types explicitly or instead should check for all types which have a a narrower type than int.

It seems to me that any restriction are applied to switch block.

Is admited to switch between differnt type of signal:
float/boolena
int/bool
int/float

Instead GMG rules suggest the user to use types properly.

Giacomo

I didn't found any explicit rule that prohibit a misleading use of float

1) float as vector index into stateflow/simulink
2) logical operation between float in stateflow and simulink

General Modelling rules cover this topic but SLSF seems to me not!

May you confirm that I've properly read the standard ?

Giacomo

Our concern is also related to unoptimized code that should be produce by these bad modelling style

Hello.
My PC-LINT tool gives me an error of violating of rules 11.1, 11.2, 11.3, 11.4 (cast from unsigned char to pointer ) on the line 2:

line 1: unsigned char* ptr;
line 2: ptr=(unsigned char*)0x12;

The idea behind is that I want to initialize a pointer with a non-zero address in a MISRA-compliant style.

Thank you for the answer.

Best regards.

The rule applies to structure definitions that are incomplete, but I see from exemplar suite file mc2_1801.c the following unexpected violation:

struct {
int8_t a;
int8_t b [ ]; /* Not Compliant - constraint error 6.5.2.1 */
} mc2_1801_st = { 1, { 2, 3, 4 } };

Are you including as "incomplete" any structure that has a flexible array member?

Apart from this, what other coding practice is left that might cause a problem?

If the type is incomplete, a compile error will result from any attempt to create an object of that type or refer to its members or to compute sizeof, etc.

So I cannot think of any legal C code that would be a violation of this rule.

I have been using PCLint to analyse code which have constants defined in header files e.g.

const uint8 PLD_READ_VERIFICATION_BYTE_4 = 7;

PCLint claims that this violates rule 3-1-1. Is this a true interpretation of this rule or are constants permitted in header files?

Mark.