Welcome to the MISRA discussion forum

Suppose I have:

In C++ Standard, There are not exist NULL(its C standard).
So, Programmer should to know about this and Use constant 0 instead of NULL macro.

Hello,

my MISRA checker generates a MISRA violation 10.1 (The signedness of an integer type is converted implicitly.(signed -> unsigned)), although a casting is done.

My C code:

1: #include
2: typedef unsigned char U8;
...
w: U8 WriteProtect = (U8) true;
....
x: if(WriteProtect == (U8) false) {
....
y: WriteProtect = (U8) true;
....
z: }

The MISRA checker identifies line x and y as a rule 10.1 violation. Why is this a rule 10.1 violation although a casting is done? Interestingly the MISRA checker identifies line w as OK. Have anybody an idea what is my fault?

Is it generally impossible in MISRA to assign a signed var to an unsigned var?

hello guys

i've a problem. i'm not sure if the following code is compliant to the Rule 11.3:

Does the following example violate rule #2.4:

rule 19.1 example :

a = b; /* Compliant - exception 1 */

a and b are not overlapping object.
Therefore, this code is improper as the example.
Is it right?

Rule 15.3 Example
void f1(int32_t a){
if ( a 0){
L2:
;
}
}
has some unreachable codes. So I think
void f1(int32_t a){
if ( a 0){
L2:
;
}
}
are enough and no unreachable codes.

Dr. Ogawa Kiyoshi
https://twitter.com/kaizen_nagoya/, http://researchmap.jp/kaizen/MISRA-C/

In Rule 13.2 Example

#define COPY_ELEMENT ( index ) ( a[( index )] = b[( index )] )

The print may have a space between COPY_ELEMENT and '('.
It generate
( index ) ( a[( index )] = b[( index )] ) ( i++ );

#define COPY_ELEMENT( index ) ( a[( index )] = b[( index )] )
"no space" seem proper.

Dr. Ogawa Kiyoshi
@kaizen_nagoya, http://researchmap.jp/kaizen/MISRA-C/

Hi Folks,

I'm trying to come to an understanding of an issue associated with MISRA 2012 Rule 12.2 and the interpretation of constant size. Here is the situation I'm dealing with.

=====================================================================
int32_t result;

result = (1

There shall be no more than one definition of each virtual function on each path through the inheritance hierarchy.

If I'm interpreting this rule correctly, once you define a virtual function for a derived class with the virtual base class as an ancestor, no more derivations in the chain can override the first definition.

This would seem to cripple a key advantage of using classes and an object-oriented design.

Isn't it pretty common to override a virtual member function in a child class even if the parent class has provided a different definition? Please explain.