Welcome to the MISRA discussion forum

According p.8.10.2 and Appendix D, there are 5 ranks for signed and unsigned types for variables, defined, presumably, by their standard types. In particular, standard types int, long and long long are considered to have all different ranks.

According to p. D.3, for a constant, rank of its essential type is determined by its value. Now assume there is a (signed) constant that requires, say, 32 bits to represent the value. Is its rank the same as that of a signed int or signed long variable? And, correspondingly, for a 64-bit constant, will its rank be the same as that of signed long or signed long long variable?

Thank you.

Hello everyone, I am a Product Manager/Owner at Klocwork/Roguewave and our developers had couple of questions with respect to rule interpretation.
Is there an email address I can use to contact someone who could answer this? Or appropriate board where I can get some information in a timely fashion.

Thank you!
Igor Gvero

The third and last example of Rule 11.3 states that

Quote:is non-compliant because the unqualified pointer types are different, namely “pointer to const-qualified int” and “pointer to int”

Quote:This rule applies to the unqualified types that are pointed to by the pointers.

I have a question about Rule2.1.

Are these samples correct?
The else statement is null statement or not.

sample_1
if ( a= 5 ) {
y=3;
}else{
y=0; /* not compliant */
}

sample_2
if ( a= 5 ) {
y=3;
}else{
; /* compliant */
}

I think if the else statement is null statement the code is reachable.
Is is correct?

And how about is default label?

In case all case is coded,if default label has null statement , the code is reachable.
Is it correct?

Please teach me.

Regards

We're having issues complying with rule 3-4-1 in a number of functions that initialise a temporary variable which is subsequently modified and tested within a loop. I appreciate in many cases this can be resolved with recursion, however, it seems an excessive solution given the additional considerations required.

The only other solution we've found (that doesn't conflict with other rules) is to declare and initialise a struct with the members set to the required values. e.g.

in the Example Suite, R_05_03.h

#ifndef R_05_09_
#define R_05_09_

should be

#ifndef R_05_03_
#define R_05_03_

BTW, now I compile the Example Suite using LLVM and add some supporting codes.
The memo for compile the Example Suite is
http://researchmap.jp/joydcij21-1861956/#_1861956

If there are any problems, please inform me.
I have updated weekly.

In MISRA C:2012 Examples Suite, D_04_02.c has no function.
If you compile D_04_support.c or D_04_system.c then a link error should be occured.

For example, at LLVM(clang)
"_D_4_2", referenced from:
_D_4_main_support in D_04_support.o
_main in D_04_system.o
ld: symbol(s) not found

You could compile with adding a function D_4_2(){} in D_04_02.c or removing D_4_2( ); in D_04_support.c and D_04_system.c.

BTY.
In the Example suite, xx_system call xx_support, but both of them have same individual function calls.
it may be redundant.

Dr. OGAWA Kiyoshi

My static analyser tool throws a warning when small unsigned integer (short or char) operand is used with bitwise operator.

Quote:The results of some bitwise operations on signed integers (6.5).

Quote:Shift and bitwise operations should only be performed on operands of essentially unsigned type. The numeric value resulting from their use on essentially signed types is implementation-defined.

Rule 2.5 Is #undef considered a “use” of a macro”?
For example