Welcome to the MISRA discussion forum

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.

We are using an ARM development suite where standard libraries are provided with the tool suite. Looking at the MISRA rules, I found quite a few which prohibit using such and such function (atoi, etc...). Which means that implicitly, the other functions can be used.
However, rule 3.6 requires that all libraries (including the ones provided with the compiler) be "subjected to appropriate validation".
Could you expand on what this means in regards to standard libraries? Do we need to require the vendor to certify he is MISRA compliant? If not possible, does this means we have to write our own version, so that we are sure it is compliant?
Thanks
Michel Campmas
Cypress Semiconductor

//Example 1:

struct xyz {
unsigned char bit:1;
}abc={0} ; // Is this assignment to bit-field is compliant to MISRA rule10.1 and Why?