米斯拉 C++规则 5-0-3 误报警告

Question

我的静态分析器抛出以下警告：

MCPP 规则 5-0-3：这个复杂的表达式被隐式转换为 不同的基本类型

以下代码的

void func(const uint32_t arg)
{
    //32U has underlying type uint8_t
    const uint32_t u32a = arg % 32U; //warning issued in this line
    const uint32_t u32b = (arg % static_cast<uint32_t>(32U)); //same warning issued in this line
    const uint32_t u32c = static_cast<uint32_t>(arg % 32U); //compliant
}

：根据 MISRA 底层类型转换规则：

否则，如果两个操作数都是整型，则其基础类型 可以使用以下命令找到表达式：

– 如果类型 操作数大小相同，并且其中一个是无符号的，结果是 未签名。

– 否则，结果的类型是较大的类型 类型。

我认为此警告可能是误报，因为尽管 32U 是 uint8_t，但表达式应采用较大类型的基础类型，在本例中为 >uint32_t，因此不需要 static_cast。

您是否同意这是误报？还是我看错了？

编辑： MISRA 标准规定：

因此，整数常量表达式的基础类型是 定义如下：

1. 如果表达式的实际类型是有符号整数，则基础类型定义为最小有符号整数类型 能够体现其价值。

2. 如果表达式的实际类型是无符号整数，则基础类型定义为满足以下条件的最小无符号整数类型： 能够体现其价值。

3. 在所有其他情况下，表达式的基础类型被定义为与其实际类型相同。

第二点是我必须假设 32U 具有 uint8_t 底层类型的原因。

Answer 1

我认为此警告可能是误报，因为尽管 32U 是 uint8_t

32U 不是 uint8_t在任何平台上。对于整数文字，您可以表达的最小类型是 int/unsigned int。 根据cppreference nnnnU即可
unsigned int、unsigned long int 或 unsigned long long int。它确实选择了第一个可以存储文字的类型，因此 32U 是一个 unsigned int。

因此，如果您想保证 32U 与 uint32_t 的类型相同，那么您需要在右侧进行强制转换。

Answer 2

32U 的类型为 unsigned，它可能与 uint32_t 不同。与您的声明相反，它永远不是 uint8_t 类型

unsigned 仅保证能够表示 0 到 0 范围内的值code>65535，尽管允许支持更大的范围。它实际上可以代表什么是实现定义的。但是，它不能是 uint8_t，因为 uint8_t 无法表示 unsigned 所需的范围。

这实际上意味着三种可能性：unsigned 可能是 16 位类型、32 位类型，甚至是 64 位类型 - 并且它们分别较小、大小相同，或大于uint32_t。

因此，表达式 arg % 32U 的结果可能是 uint32_t 类型（如果 unsigned 是 16 位），uint32_t code> （如果 unsigned 和 uint32_t 都是相同的 32 位类型），或 unsigned （如果unsigned 是 64 位类型）。在最后一种情况下，需要从 unsigned 到 uint32_t 的转换来初始化 u32a。

您的静态分析器正在警告您系统之间潜在的行为差异。

所以，不，这不是误报。

Answer 3

您已找到相关部分。文字所在表达式的类型是无符号的，因此底层类型是可以容纳无符号值32的最小类型，即uint8_t.如果文字是没有 U 后缀的 32，它将具有完全相同的基础类型（尽管这会违反其他 MISRA 规则）。

MISRA 的目的是在具体表达式 uint32_t arg; 中实现。 ... arg % 32U 永远不会发生危险的隐式转换。话虽如此，您可以安全地将文字转换为 uint32_t ，这应该会消除所有警告。确保代码中没有隐式类型提升是良好的编程实践，无论 MISRA 说什么/没有说什么。

如果静态分析器的目的只是检查一般的隐式升级，那么警告就可以了。如果静态分析仪的目的是检查 MISRA 合规性，那么它就是误报。

无论工具的用途如何，arg % static_cast(32U) 行永远不应产生任何形式的诊断。这肯定是误报。