Welcome to the MISRA discussion forum

The C standard states that "The typedef specifier is called a ‘‘storage-class specifier’’ for syntactic convenience only;".

Does 19.4 allow a macro to expand to 'typedef'?

The initialization:
uint8_t d = ((uint8_t) 0x1U) | ((uint8_t) 0x2U);
should, according to the MISRA-C guidelines, generate an error for rule 10.1. The initializer, i.e. the integer constant expression, has the underlying type of uint8_t, but that type is overruled by the explicit rule for integer constant expressions in 6.10.4 that says that the signedness/unsignedness of the underlying type should be taken from the actual type of the integer constant expression, but only if it is signed or unsigned int. In this case it is signed int. Giving the rule 10.1 breakage. Is this really the intention of the MISRA-C guidelines for integer constant expressions?

I don't believe my compiler's interpretation of rule 15.4 is consistent with the Standard's...

The Standard says:

Consider the following:

File1.h:
typedef short int int16_t;

File2.h:
short int foo(short int a);

File3.h:
int16_t foo(int16_t a);

Does this break any MISRA rules? I ask because rule 8.3 states that for a function, the types in the prototype must match the types in the definition *exactly*. However, rule 8.4 states that when an object *or function* is declared more than once, the types in the declarations must be compatible, which is a weaker requirement. Why were the words "or function" included in rule 8.4?

My intepretation is that if my source code includes a definition of function foo, then I must be violating rules 8.3 (because at most one of the prototypes can have types that exactly match the types in the definition); but it my code doesn't include a definition for foo (e.g. because it is in a compiler-supplied library), I am free to provide two or more prototypes for it with non-identical but compatible types.

I have recently come across code similar to the following:

I recently came across some code similar to the following:

Why is the last code line (array element initialization) in the code below being cited for 13.6 violation by Crystal Revs MISRA checker:

Is there a MISRA-compliant way to have effectively boolean bit-fields? Single bit-fields can't be signed per Rule 6.5. So the bit-fields must be unsigned. Now we need to pick the signedness of the boolean type.

If we go with

I have received a news letter which states that "A reminder that the MISRA Guidelines for Safety Analysis of Vehicle Based Programmable Systems (MISRA SA) will be very helpful to an organization seeking to implement functional safety management processes for the first time. While ISO 26262 focuses on stating requirements, MISRA SA provides guidance on understanding such requirements."

I don't have idea about ISO 26262. Process champion is looking for more details. Is this MISRA SA applicable for software team??? Please let me know what is the advantage to the community if we follow this process?

Hi,

Whilst testing my implementation of rule 4.2 with a simple example, I got a warning about rule 11.5. It is on the following simple example:

void main() {
char * x="abcd";
return;
}

that is automatically translated by CIL into the following C code, where one can notice a new cast.

void main() {
char *x;
x=(char *)"abcd";
}

the 11.5 warning concerns the assignment, where it complains that the attribute const has been lost.
Indeed, the rhs expression has type const char *, so this seems normal.

A correct writing would be:

void main() {
char *x;
char content[4]="abcd";
x=&content[0];
}
which does not generate the 11.5 warning as we have well typed the constant and assigned the first element's address into x.
BUT, now I get a warning about rule 9.2 explaining that I haven't a braced expression on the rhs of the assignement, to initialize the array!!

I can correct this by decomposing "abcd" into {'a','b','c','d''} which removes the last warning but gets tedious.

So my question is: does MISRA discourage programmers from using strings?