misra-c | MISRA-C:2004 simplest rules | Plugin library

There is one thing every MISRA-C checker needs to know and that's what type you use as bool. This is necessary since MISRA-C:2012 still supports C90 which didn't have standard support for a boolean type. (C99 applications should use _Bool/bool, period.) It also needs to know which constants that false and true correspond to, in case stdbool.h with false and true is unavailable. This could be the reason why it asks which compiler that is used. Check Appendix D - Essential types for details.

Type sizes of int etc isn't relevant for the MISRA checker to know. Though it might be nice with some awareness of non-standard extensions. We aren't allowed to use non-standard extensions or implementation-defined behavior without documenting them. The usual suspects being inline assembler, interrupts, memory allocation at specific places and so on. But once we have documented them in our deviation to Dir 1.1/Rule 1.1, we might want to disable warnings about using those specific, allowed deviations. If the MISRA checker is completely unaware of a certain feature, then how can you disable the warning caused by it?

I have never used Misra but I find your code hard to read with all that noise of typedefs, casts and parenthesis. My suggestion would be to simplify and split the problem into smaller parts along these lines:

Variables defined inside of a function without the static keyword have automatic storage duration. These variables are typically created on the stack when they come into scope.

This means that if such variables are initialized then there is a cost at runtime to initialize them.

Only variables with static storage duration, i.e. variables declared at file scope or with the static keyword, are typically defined in either .data if explicitly initialized or .bss if not.

When compiling this code under gcc 4.8.5 with -O0, defining MISRA_VIOLATION_DISABLED resulting in the following additional code:

I had a look at LOG4CPLUS_INFO and that is a macro defined as:

The concept underlying type was used in the older MISRAs, nowadays deprecated and replaced with essential type categories. The definition of underlying type is the type that each of the operands in an expression would have if not for implicit type promotion.

In the expression ~0U, the type of the integer constant 0U is unsigned int. It is not a small integer type, so no integer promotion takes place upon ~. The underlying type is the same as the actual C language type, unsigned int.

unsigned val = ... assigns an unsigned int to an unsigned int. No lvalue conversion through assignment or other such implicit assignment takes place. The underlying type remains unsigned int.

Thus if your tool gives a warning about no cast to underlying type on the line unsigned val = ~0U;, your tool is simply broken.

From what i understand, the idea is to have to maximum value of an unsigned int

Very likely.

However, i would like to know if there is something wrong with this code.

No, nothing is wrong with your code. However, other MISRA rules require you to replace the default "primitive types" with types from stdint.h (or equivalent on pre-C99 compilers). So in case this is a 32 bit system, the MISRA compliant version of your code is uint32_t val.

uint16_t val2 = (uint16_t)(~0U);

This is MISRA compliant code. The underlying type of the assignment expression is uint16_t. Casting to uint16_t is correct and proper practice. Again, your tool is broken.

In MISRA-C:2012 there is the advisory rule 17.5 which requires that array parameters to functions should have bounds specified, to enable out-of-bounds checking of the array inside that function.

There was a rule in earlier MISRA-C that favoured the use of array syntax notation (int []) over pointer notation (int*) for function parameters, but it was a bit misguided since all array parameters get adjusted ("decay") into pointers to the first element anyhow, so the array syntax in itself doesn't add anything unless the bounds are specified. That rule was rewritten into what's currently advisory rule 17.5.

Rule 18.1 (required) says that any pointer arithmetic should result in a pointer that points at the same array as the original operand. This should (arguably) be used to cover the out of bounds case too, since arr[i] is equivalent to *(arr+i) and you can't actually access an array with the array subscripting [] operator, only a pointer (see Do pointers support "array style indexing"?).

There's also the general rule 1.3 stating that the program should not contain any form of undefined behavior, which is meant to cover all cases of UB that aren't handled by other more specific rules.

But in the end, this will be a quality of implementation matter for the static analyser. When they are able to, most such tools perform out-of-bounds checks anyway, regardless of MISRA-C.

Unfortunately, MISRA-C is suffering from the same misguided ideas as the C11 committee when it comes to VLA - C11 made VLA optional and MISRA-C bans them completely. Both committees failed to take modern C programming in account, where you can use a pointer to VLA to increase type safety and static analysis possibilities, namely:

As the MISRA-C document says, it is only sensible to check this dynamically at run-time or during code review. Which of course won't stop dysfunctional static analysers from trying to do it during static analysis anyway...

Why is parasoft software still reporting an error for the right-hand operand being (32u - n) despite the limit check?

Likely because it is bugged and reports a false positive.

Unless of course it spotted that some caller-side code is providing an n which is larger than 32. Some static analysers are able to give somewhat smarter warnings when they check the project as whole rather than individual translation units, one at a time.

What is the correct way to resolve this violation?

Your original code is fine and apart from 32 -> 32u, it is MISRA compliant. Don't clutter it up with defensive programming just to silence the potentially broken tool. Only add such checks if you have reason to believe that n will actually be zero or larger than 32.

For MISRA-C compliance, it should be sufficient to state that the case of a variable n will be covered by code review.

(To be picky, MISRA-C:2004 doesn't allow inline since it doesn't allow C99, you need MISRA-C:2012 for that.)

It seems like you have found a bug. Your approach looks correct to me.

For the following C code (here in the file misra_suppression_test.c) the suppression works:

The integer constant "1" however is of the first type in the list int, long int, unsigned long int...

Correct. Integer constants like 1 are of type int and as far as MISRA-C is concerned, the underlying type is also int. The definition is (MISRA-C:2004 6.10.4)

The term "underlying type" is defined as describing the type that would be obtained from evaluating an expression if it were not for the effects of integral promotion.

The line signed long int test = -1; is MISRA-C:2004 (and MISRA-C:2012) compliant.

• The expression -1 contains no implicit promotions in itself. Integral promotion does not apply.
• Thus -1 has underlying type signed int and upon assignment, it is implicitly converted to a wider integer type with the same signedness, which is fine.
• The intention is to create a signed variable, so the rule about u suffix does not apply.
• Furthermore, the rule 10.1 against implicit conversions from a so-called "complex expression" into different a type does not apply either, since -1 is a constant expression, not a complex expression (see MISRA-C:2004 6.10.5).

So this is yet another tool bug. The tool seems to picking the wrong underlying type of an expression, which would be a severe bug.

signed long int test = -1L; is not necessary for compliance, although it is also compliant code.