Disable Rule 2.2 checker

Coverity MISRA checking is customized using the --misra-config command line option, which is followed by a JSON-syntax configuration file name. See the Synopsys article How to analyze primary source files with MISRA checkers?

(The fact that MISRA_CAST responds to --disable is an exception because, internally, it works quite differently than the others.)

For example, to disable rule MISRA 2004 2.2, create a file called, say, MISRA_c2004.config with contents:

{ 
  version : "2.0", 
  standard : "c2004", 
  title: "Customized MISRA 2004 Compliance", 
  deviations : [ 
    {
      deviation: "Directive 2.2",
      reason: "We allow // comments here because ... ."
    }
  ]
}

Ideally, the reason should explain why your organization has chosen to disable the rule or contain a pointer to or citation of some other document containing the rationale. I'm not an expert on MISRA compliance, but my understanding is a MISRA auditor would want to see evidence that the decision was made with due consideration to the relevant threats to the safety of the system, not merely on a whim or for programmer convenience. The configuration file demands a reason string in order to ensure that reason is readily available to satisfy an audit.

Then add --misra-config MISRA_c2004.config to the cov-analyze command line.

Be aware that I have not tested the above configuration file as I don't have access to the tool anymore. Please comment on whether it works so I can fix this answer or delete this paragraph.

Scott gives the mechanism for resolving your problem in Coverity.

This post (a bit too long for a comment) gives some background.

--

MISRA C:2004 (published in 2004) is aligned with ISO/IEC 9899:1990 (aka C90) - the C++ style // comments were not part of C90, and although permitted by some compilers as an extension, there were inconsistent implementations leading to known issues at the time... plus it was a language extension.

Although a required MISRA C:2004 Rule 2.2 was (and still is) a common subject of a deviation - the process for which requires the developer to make sure that the known problems are not experienced.

Of course, if you are using MISRA C:2004 with C99 or later, you will also need a deviation against MISRA C:2004 required Rule 1.1 , and understand the implications of that decision.

--

MISRA C:2012 (first published in 2012/2013) extends MISRA C to cover ISO/IEC 9899:1990 (aka C99) in which the C++ style // is now a part of the language.

As such, MISRA C:2012 does not have an equivalent guideline to MISRA C:2004 Rule 2.2... and therefore the // comment can be freely used without a deviation.

If possible, I would encourage a transition to MISRA C:2012 for a number of reasons... C99 support (and hence // comments) is but one.

--

** See profile for affiliation **