禁用规则2.2检查器
我的商店正在使用Coverity 2019.3。
我们已经启用了Misra-C 2004。
我想禁用Misra-C 2004规则2.2:源代码应仅使用 / * ... * /注释。
cov-Analyze
命令具有禁用
选项,但仅显示检查器。例如,可以使用- 禁用
将其用于Misra-cast。
我们在Windows 10上使用Coverity 2019.3,其中包括IAR 8.4编译器(构建器)。
那么,如何配置覆盖率以禁用Misra-C 2004,规则2.2?
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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
使用
- misra-config
命令行选项对Coverity Misra检查进行自定义,其后是JSON-Syntax配置文件名。请参阅Synopsys文章用Misra Checker分析主源文件?(
misra_cast
响应的事实 - disable
是一个例外,因为它在内部的工作方式大不相同。
禁用该规则或包含指向或引用包含基本原理的其他文件的指针。我不是Misra合规性的专家,但我的理解是Misra审计师希望看到证据表明该决定是在适当考虑系统安全的相关威胁的情况下做出的,而不仅仅是兴起或程序员方便。配置文件需要一个原因字符串,以确保很容易获得原因以满足审核。
然后添加
- misra-config misra_c2004.config
到cov-analyze
命令行。请注意,我没有测试上述配置文件,因为我不再可以访问该工具。请评论它是否有效,以便我可以解决此答案或删除本段。
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: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 thecov-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)提供了解决掩护问题的机制。
这篇文章(有点太长时间评论)提供了一些背景。
-Misra
C:2004(2004年出版)与ISO/IEC 9899:1990(又名
C90
)一致 - C ++样式//
评论不是C90的一部分。 ,尽管某些编译器被允许作为扩展名,但在当时的实现不一致,导致已知问题……此外,这是一种语言扩展。尽管A 必需的 Misra C:2004年规则2.2是(现在仍然是)偏差的常见主题 - 该过程要求开发人员确保未遇到已知问题。
当然,如果您使用Misra C:2004与C99或更高版本,您还需要对Misra C:2004 必需规则1.1进行偏差,并了解该决定的含义。
-Misra
C:2012(2012/2013首次发布)扩展了Misra C以覆盖ISO/IEC 9899:1990(又名
C99
),其中C ++样式// 现在是语言的一部分。
因此,Misra C:2012与Misra C:2004年规则2.2 ...没有等效的指南,因此
//
评论可以在没有偏差的情况下自由使用。如果可能的话,由于多种原因,我会鼓励向Misra C:2012过渡...
C99
支持(因此//
注释)只是一个。-
** 请参阅分支机构的个人资料 **
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 **