gpt4 book ai didi

c - MISRA 2012 违规 - 类型不匹配(规则 10.1、10.4)

转载 作者:太空狗 更新时间:2023-10-29 17:24:05 29 4
gpt4 key购买 nike

我面临着我无法理解的 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 指出对 unsigned int 进行 OR 运算应该没有问题。 (PC-Lint 通过了第一个 OR 操作并提示第二个操作!!)

规则 10.4 规定操作的操作数应具有相同的基本类型。

尽管所有操作数都声明为 uint8_t,但我不明白为什么存在这些违规行为?

我试过在 ORed 常量的每两个两边加上括号。我还尝试将它们全部转换为 uint8_tvolatile uint8_t。未解决违规问题。

我检查了这两个帖子( 12 )但他们没有回答我的问题。

最佳答案

I2C_CCRH_FS | I2C_CCRH_DUTY 本身符合 MISRA 标准。两个操作数基本上都是无符号的,因此子表达式很好。但是,仍然存在每个操作数到 int 的隐式转换。实践中的结果是 int 类型。

在伪代码中:当你执行 (result as int) | I2C_CCRH_CCR,隐式提升前的操作数类型为int | uint8_tuint8_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 后缀。

关于c - MISRA 2012 违规 - 类型不匹配(规则 10.1、10.4),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/50736432/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com