MISRA 2012 违规 - 类型不匹配(规则 10.1、10.4)
MISRA 2012 violation - Type mismatch (Rules 10.1, 10.4)
我遇到了无法理解的 MISRA C 2012 违规问题。以下是代码:
#define I2C_CCRH_FS ((uint8_t)0x80)
#define I2C_CCRH_DUTY ((uint8_t)0x40)
#define I2C_CCRH_CCR ((uint8_t)0x0F)
typedef struct I2C_struct
{
volatile uint8_t CR1;
volatile uint8_t CR2;
volatile uint8_t CCRL;
volatile uint8_t CCRH;
} I2C_TypeDef;
#define I2C_BaseAddress 0x5210
#define I2C ((I2C_TypeDef *) I2C_BaseAddress)
I2C->CCRH &= ~(uint8_t)((I2C_CCRH_FS | I2C_CCRH_DUTY) | I2C_CCRH_CCR);
在前面的代码中,PC-Lint 抱怨说:
Unpermitted operand to operator '|' [MISRA 2012 Rule 10.1, required]
Mismatched essential type categories for binary operand [MISRA 2012 Rule 10.4, required]
规则 10.1 指出 ORing unsigned int
s 应该没有问题。 (PC-Lint 通过了第一个 OR 运算并抱怨第二个运算!!)
规则 10.4 规定操作的操作数应具有相同的基本类型。
尽管所有操作数都声明为 uint8_t
?
,但我不明白为什么存在这些违规行为
我试过在 ORed 常量的每两个两边加上括号。我也试过将它们全部转换为 uint8_t
和 volatile uint8_t
。未解决违规问题。
我查看了这两个帖子 (1, 2),但它们没有回答我的问题。
当您执行按位运算 (I2C_CCRH_FS | I2C_CCRH_DUTY)
时,结果会提升为整数。请参阅整数提升规则
因此上述操作的结果与下一个按位或| I2C_CCRH_CCR
之间发生不匹配
要解决此问题,您需要向 BOTH 按位或运算的结果添加强制转换。
第一次转换需要将 ~
运算符的结果从 int
转换回 unsigned
I2C->CCRH &= (uint8_t)~(uint8_t)((uint8_t)(I2C_CCRH_FS | I2C_CCRH_DUTY) | I2C_CCRH_CCR);
解释一下
I2C->CCRH &= (uint8_t)~ // Required to cast result of ~ operator to uint8_t
(uint8_t) // Casts the result of the 2nd OR to uint8_t
((uint8_t) // Casts the result of the 1st OR
(I2C_CCRH_FS | I2C_CCRH_DUTY) // 1st OR
| I2C_CCRH_CCR); // 2nd OR
I2C_CCRH_FS | I2C_CCRH_DUTY
本身就符合 MISRA 标准。两个操作数基本上都是无符号的,因此子表达式很好。但是,仍然存在每个操作数到 int
的隐式转换。实践中的结果是 int
.
类型
在伪代码中:当您执行 (result as int) | I2C_CCRH_CCR
时,隐式提升之前的操作数具有类型 int | uint8_t
。 uint8_t
也将在这里提升为 int
的整数。您有不同符号的操作数。
(我猜该工具会抱怨 10.4,因为整数提升是通常算术转换的一部分,这就是 10.4 的意义所在。)
整个表达式在实践中不会造成任何问题,因此警告主要是迂腐的。但是想象一下,如果您在 ~(I2C_CCRH_FS | I2C_CCRH_DUTY) | I2C_CCRH_CCR)
的情况下没有强制转换 - 您最终会得到一个负数,类似于 0xFFFFFFxx
以 2 的补码表示。那可能很危险。
要解决此问题,您有两种选择:
- 对于每个操作,将结果转换回预期类型。这往往是MISRA-C的精神。
- 在操作前将操作数转换为大型无符号类型。通常更具可读性的 IMO。
另请注意,~
运算符不应与带符号的操作数一起使用!这违反了规则 10.1。转换回 uint8_t
应该最后完成。
长话短说;博士。如何使代码符合 MISRA 标准:
你要么必须做这样的半糟糕的事情:
I2C->CCRH &= (uint8_t) ~ (uint8_t) ((uint8_t)(I2C_CCRH_FS | I2C_CCRH_DUTY) | I2C_CCRH_CCR)
有点乱。我会提前施法。假设 32 位 CPU:
I2C->CCRH &= (uint8_t) ~( (uint32_t)I2C_CCRH_FS | // comment explaining FS
(uint32_t)I2C_CCRH_DUTY) | // comment explaining DUTY
(uint32_t)I2C_CCRH_CCR ); // comment explaining CCR
上面的风格在处理 MCU 寄存器等时很有用。此代码可以接受,但可以进一步简化。
如果可以将定义更改为 #define I2C_CCRH_FS 0x80u
,那么您将得到:
I2C->CCRH &= (uint8_t) ~(I2C_CCRH_FS | I2C_CCRH_DUTY | I2C_CCRH_CCR);
它仍然符合 MISRA 标准,因为 MISRA 喜欢方便的小 u
后缀。
我遇到了无法理解的 MISRA C 2012 违规问题。以下是代码:
#define I2C_CCRH_FS ((uint8_t)0x80)
#define I2C_CCRH_DUTY ((uint8_t)0x40)
#define I2C_CCRH_CCR ((uint8_t)0x0F)
typedef struct I2C_struct
{
volatile uint8_t CR1;
volatile uint8_t CR2;
volatile uint8_t CCRL;
volatile uint8_t CCRH;
} I2C_TypeDef;
#define I2C_BaseAddress 0x5210
#define I2C ((I2C_TypeDef *) I2C_BaseAddress)
I2C->CCRH &= ~(uint8_t)((I2C_CCRH_FS | I2C_CCRH_DUTY) | I2C_CCRH_CCR);
在前面的代码中,PC-Lint 抱怨说:
Unpermitted operand to operator '|' [MISRA 2012 Rule 10.1, required]
Mismatched essential type categories for binary operand [MISRA 2012 Rule 10.4, required]
规则 10.1 指出 ORing unsigned int
s 应该没有问题。 (PC-Lint 通过了第一个 OR 运算并抱怨第二个运算!!)
规则 10.4 规定操作的操作数应具有相同的基本类型。
尽管所有操作数都声明为 uint8_t
?
我试过在 ORed 常量的每两个两边加上括号。我也试过将它们全部转换为 uint8_t
和 volatile uint8_t
。未解决违规问题。
我查看了这两个帖子 (1, 2),但它们没有回答我的问题。
当您执行按位运算 (I2C_CCRH_FS | I2C_CCRH_DUTY)
时,结果会提升为整数。请参阅整数提升规则
因此上述操作的结果与下一个按位或| I2C_CCRH_CCR
要解决此问题,您需要向 BOTH 按位或运算的结果添加强制转换。
第一次转换需要将 ~
运算符的结果从 int
转换回 unsigned
I2C->CCRH &= (uint8_t)~(uint8_t)((uint8_t)(I2C_CCRH_FS | I2C_CCRH_DUTY) | I2C_CCRH_CCR);
解释一下
I2C->CCRH &= (uint8_t)~ // Required to cast result of ~ operator to uint8_t
(uint8_t) // Casts the result of the 2nd OR to uint8_t
((uint8_t) // Casts the result of the 1st OR
(I2C_CCRH_FS | I2C_CCRH_DUTY) // 1st OR
| I2C_CCRH_CCR); // 2nd OR
I2C_CCRH_FS | I2C_CCRH_DUTY
本身就符合 MISRA 标准。两个操作数基本上都是无符号的,因此子表达式很好。但是,仍然存在每个操作数到 int
的隐式转换。实践中的结果是 int
.
在伪代码中:当您执行 (result as int) | I2C_CCRH_CCR
时,隐式提升之前的操作数具有类型 int | uint8_t
。 uint8_t
也将在这里提升为 int
的整数。您有不同符号的操作数。
(我猜该工具会抱怨 10.4,因为整数提升是通常算术转换的一部分,这就是 10.4 的意义所在。)
整个表达式在实践中不会造成任何问题,因此警告主要是迂腐的。但是想象一下,如果您在 ~(I2C_CCRH_FS | I2C_CCRH_DUTY) | I2C_CCRH_CCR)
的情况下没有强制转换 - 您最终会得到一个负数,类似于 0xFFFFFFxx
以 2 的补码表示。那可能很危险。
要解决此问题,您有两种选择:
- 对于每个操作,将结果转换回预期类型。这往往是MISRA-C的精神。
- 在操作前将操作数转换为大型无符号类型。通常更具可读性的 IMO。
另请注意,~
运算符不应与带符号的操作数一起使用!这违反了规则 10.1。转换回 uint8_t
应该最后完成。
长话短说;博士。如何使代码符合 MISRA 标准:
你要么必须做这样的半糟糕的事情:
I2C->CCRH &= (uint8_t) ~ (uint8_t) ((uint8_t)(I2C_CCRH_FS | I2C_CCRH_DUTY) | I2C_CCRH_CCR)
有点乱。我会提前施法。假设 32 位 CPU:
I2C->CCRH &= (uint8_t) ~( (uint32_t)I2C_CCRH_FS | // comment explaining FS
(uint32_t)I2C_CCRH_DUTY) | // comment explaining DUTY
(uint32_t)I2C_CCRH_CCR ); // comment explaining CCR
上面的风格在处理 MCU 寄存器等时很有用。此代码可以接受,但可以进一步简化。
如果可以将定义更改为 #define I2C_CCRH_FS 0x80u
,那么您将得到:
I2C->CCRH &= (uint8_t) ~(I2C_CCRH_FS | I2C_CCRH_DUTY | I2C_CCRH_CCR);
它仍然符合 MISRA 标准,因为 MISRA 喜欢方便的小 u
后缀。