My shop is using Coverity 2019.3.
We have MISRA-C 2004 enabled.
I want to disable MISRA-C 2004 Rule 2.2: Source code shall only use /*... */ comments.
The cov-analyze
command has disable
option, but it only shows checkers. For example, one could use --disable
for MISRA-CAST.
We are using Coverity 2019.3 on Windows 10, with IAR 8.4 compiler (builder).
So, how can I configure Coverity to disable MISRA-C 2004, Rule 2.2?
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 **
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.