Silencing the checker

[JonM]

What do people think of comments like these in code

/* defines to satisfy the MISRA checker tool */
... inevitable strange pre-processor magic


#if defined ( MISRA_CHECK )
.. behaviour 1
#endif

I see worrying amounts of it in a project I am working with and it makes me think I am working with unfinished code where the developers would rather continue writing insecure code by keeping a checker quiet than addressing the root causes. That this has been allowed by the checking tool vendor without

Does this kind of thing satisfy the spirit of MISRA and should checking tool vendors be inventing their own suppression language to litter the C-code with?

Does it break rule 2.4 - sections of code should not be commented out

Could we have a rule that bans checking tool logic, defines and comments in production code. Could we add a rule that requires checking tool vendors be required to discard the content of all well formed comments and not add mechansims for the programmer to determine if a checking tool is parsing the code? please.

Jonathan

[Lundin]

It is not fine to run the code through the static checker, then alter the code. If you change some compiler switches, you must run the code through the tool again or it isn't MISRA-compliant, since MISRA enforces a check by a static analyzer.

However, have in mind that static analyzers tend to be incredibly picky. To filter out incorrect warnings in the tool can be complicated, or perhaps not even possible. So the reason behind compiler switches like this could be a poor static analyzer, and not necessarily just a lazy programmer (although the latter is far more common). I'd take a closer look at each row surrounded by such a compiler switch.

At any rate, it does not break rule 2.4 since that one only concerns code within comments, not within compiler switches.

I would agree that a rule banning compiler switches entirely would be in place - compiler switches (and everything else in the pre-processor) are notorious bug creators.I have banned them in the coding policy for the company I work for, as an extension to MISRA-C.

Why do you want to ban comments for? They are as much a part of the program as the source itself. If your debug and/or production code does not contain any comments, you are either writing very plain, uncomplicated programs, or you are doing something wrong.

[TheDoctor]

I have seen something similar in my travels through time and space but this time using a #pragma directive to silence the checker e.g. when the constants in a table are being initialised in the following way:

Code:

const uint8_t cTable[TABLE_SIZE] = {0, 1, 2, 3 ... };

Rather than changing these to 0U, 1U etc. to comply with Rule 10.6 the programmer had added a #pragma to turn off the tool's warning messages. At least they had added a comment in the code to this effect and I suppose they may have argued that they would document this as per Rule 3.4. However I think this supports JonM's assertion that MISRA C could add some guidance on these "defeat" mechanisms in checkers.

[Lundin]

Maybe they had choosen to deviate from the "U" rule? I do this myself and this is as I understand it a rather common deviation, since the rule doesn't make sense from a safety point-of-view, it is only there for style purposes. The way C is designed, leaving out the “U” suffix can never lead to bugs, but that is a topic for another thread...

[misra-c]

It is legitimate to "silence the checker" provided that this is covered by an appropriate deviation as defined in section 4.3.2 of the MISRA-C:2004 Guidelines. It may also be necessary to silence a checker when it delivers a false positive.

It is not legitimate to silence a checker simply to save time and / or effort during development.

Section 4.4 of the Guidelines requires that all the C code in a product shall either be compliant with the rules or be subject to documented deviations.