Question

正如标题所说，REDLIB将INT8_MIN定义为（-0x80）。当使用QAC检查MISRA-C兼容性时，这会发出警告:( INT16和INT32也是如此，分别为-0x8000和-0x80000000）

Msg(4:1281) Integer literal constant is of an unsigned type but does not include a "U" suffix.
MISRA-C:2004 Rule 10.6; REFERENCE - ISO:C90-6.1.3.2 (Integer Constants)

Msg(4:3101) Unary '-' applied to an operand of type unsigned int or unsigned long gives an unsigned result.
MISRA-C:2004 Rule 12.9; REFERENCE - ISO:C90-6.3.3.3 Unary Arithmetic Operators - Semantics

Msg(4:2850) Constant: Implicit conversion to a signed integer type of insufficient size.
MISRA-C:2004 Rule 3.1; REFERENCE - ISO:C90-6.2.1.2 Conversions (to Signed Integers)

Answer 1

在C标准（C11 6.4.4.1）中有一个关于整数文字（＆＃34;整数常量＆＃34;）的细微规则，说明如果你写一个普通的整数文字，如70000如果没有任何U或L后缀，则字面值的类型确定如下：

如果文字大到足以存储在int中，那么它的类型为int。
否则，如果文字大到足以存储在long中，那么它的类型为long。
（否则在C99 / C11的情况下，文字的长度类型为。）

因此，16位系统上的70000类型为long。

但是当你写一个十六进制整数文字（或八进制）时，会应用不同的规则。相反，编译器按以下顺序检查：

int
unsigned int
long int
unsigned long int
long long int
unsigned long long int

因此，当您在int为16位的系统上编写0x8000时，编译器会检查：它是否适合int？不能。它可以放在unsigned int中吗？是。因此0x8000的类型为unsigned int，类似0x80000000的类型为unsigned long。

这就是为什么你得到0x8000和0x80000000的MISRA错误的原因，因为在无符号类型上应用一元-是没有意义的。因此该库不符合MISRA-C。

但是，整数文字0x80在任何系统上始终都是int类型。如果您在该行上收到MISRA错误，则该规则会破坏您的静态分析工具。向PRQA提交错误报告。

为什么redlib将INT8_MIN定义为（-0x80）而不是（-0x7F）或（-INT8_MAX - 1）

1 个答案: