如何解决MISRA2004-12_8-3规则对RHS操作数32u-n具有静态分析违规,即使进行了限制检查
我目前正在尝试使用MISRA C编码标准为我的代码使用parasoft软件修复静态分析违规问题。我的代码最初具有以下功能:
static inline uint32_t rotate_right(uint32_t val,uint32_t n)
{
return (val >> n) | (val << (32 - n));
}
这将导致违反MISRA2004-12_8-3规则的静态分析。规则说
移位运算符的右侧操作数应比左侧操作数基础类型的位宽度小零至一。
规则文档指出,如果该特定规则报告违规,则
- 右侧操作数是具有负值或具有以下值的常数 超过左侧操作数的长度(以位为单位)
- 右手操作数不是常量,并且不由特定的检查 模式
由于我没有为右侧操作数使用常量,因此MISRA-C规则指示我在此语句周围进行了限制检查。 MISRA-C还指出
使用无符号整数类型将确保操作数为 非负数,因此只需要检查上限(动态地 在运行时或通过审核)。否则,两个限制都需要检查。”
由于我使用的是无符号类型uint32_t
,因此我只需要检查右侧操作数的上限。但是,对于val << (32u - n)
,我不能将n
的值设置为0u
。因此,我尝试通过添加以下检查来解决此冲突:
static inline uint32_t rotate_right(uint32_t val,uint32_t n)
{
if (n == 0u)
{
return val;
}
else if ((n > 0u) && (n <= 31u))
{
return (val >> n) | (val << (32u - n));
}
else
{
return 0u;
}
}
这样做可以解决(val >> n)
的静态分析违规问题,但仍报告(val << (32u - n))
的相同违规问题。
因此,我的问题是:
解决方法
正如MISRA-C文件所说,仅在运行时或在代码审查期间动态检查此内容是明智的。不管怎么说,那当然不会阻止功能异常的静态分析器在静态分析期间尝试这样做……
为什么尽管进行了限制检查,但是parasoft软件仍会报告右侧操作数为(32u-n)的错误?
很可能是因为它被错误修复并报告了误报。
当然,除非发现某些调用方代码提供的n
大于32
。一些静态分析器在检查项目整体而不是单个翻译单元时,能够一次发出更智能的警告。
解决此违规行为的正确方法是什么?
您的原始代码很好,除了32
-> 32u
之外,它还符合MISRA。不要用防御性编程来使它杂乱无章,只是要使可能损坏的工具静音。仅当您有理由相信n
实际上为零或大于32时,才添加此类检查。
为了符合MISRA-C的要求,应该声明代码审查将涵盖变量n
的情况。
(要挑剔,MISRA-C:2004不允许inline
,因为它不允许C99,因此您需要MISRA-C:2012。)
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。