为什么 MISRA-C 检查器提供错误检查 STM32 HAL？

Question

我已经使用 stm32cubemx 启动了一个包含 HAL 库的项目，但似乎存在 HAL 和 MISRA-C 合规性问题。

我正在使用 Keil 进行软件开发，并添加了 PC-Lint（MISRA-C 检查器）来检查 C 标准。当我运行 PC-lint 检查 MISRA-C 规则时，我收到了许多由 HAL 命令产生的 MISRA-C 2012 违规规则。

注意，除了stm32cube生成的源文件之外，我没有输入任何源文件。

例如，生成的文件包含以下两行：

HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
__attribute__((section(".revsh_text"))) __STATIC_INLINE __ASM int16_t __REVSH(int16_t value)

但我因此收到这些错误：

: Note 934: Taking address of near auto variable 'GPIO_InitStruct' (arg. no. 2) [MISRA 2012 Rule 1.3, required]
__attribute__((section(".revsh_text"))) __STATIC_INLINE __ASM int16_t __REVSH(int16_t value)

我还收到很多其他错误。根据this，HAL 符合 MISRA C 2012。有什么问题？

Answer 1

这里有两个不同的问题：静态分析器工具和 ST 库：

---

规则 1.3 只是说您的程序中不应有未定义或严重未指定的行为。一个非常广泛和模糊的规则。返回一个指向局部变量的指针 from 一个函数将违反该规则。传递一个指向局部变量的指针到一个函数不是。 HAL_GPIO_Init 除了读取它之外，对该指针不做任何事情。

这就是我们所说的“误报”，也称为工具错误。询问您的工具供应商为什么他们的工具会给出错误的诊断消息。

---

然而，由于HAL_GPIO_Init 没有修改传递的指针，它应该将函数声明为：

void HAL_GPIO_Init(GPIO_TypeDef  *GPIOx, const GPIO_InitTypeDef *GPIO_Init)`

由于他们没有这样做，因此违反了 MISRA-C 规则 8.13。该功能不符合 MISRA，除非有记录的偏差。用于实现此功能的源 Doxygen cmets（我承认在一些随机的 Github 上找到）根本没有提到 MISRA，因此可以假设该库不兼容 MISRA。

Answer 2

这不是 HAL 库的问题，只是你的代码有问题（即使它是由 Cube 生成的。

这里有什么问题？

您将引用传递给局部变量。如果code id单线程或者被调用的函数在函数返回后不使用数据，一切都很好。

但是（即使你不使用多线程）许多函数将在后台运行。例如 *_IT 和 *_DMA 函数。您将引用传递给具有自动存储持续时间的缓冲区，您将遇到大问题。

所以 Lint 是正确的。你做了一个有潜在危险的操作。

Answer 3

大多数板级支持包都会导致违反 MISRA C 规则。

这是因为，一般来说，这些 BSP 所做的事情（大多数时候）都不是好主意。有时，它们是必需的（例如，内存映射寄存器需要将整数转换为指针，尽管这可以在链接器中完成）

它们通常还包含许多特定于编译器的魔法（因此规则 1.1、规则 1.2 和指令 1.1 值得适当审查！）

因此，您需要将违规行为分为三组。

1. 纠正需要修正的违规行为
2. 需要偏离的必要违规行为
3. 您可以接受的建议违规行为（并记录您的推理）

请记住：偏差是 MISRA 合规性的可接受方面！任何说您不允许偏差的剪贴板监视器都需要重新教育。

对于第 2 组，MISRA 发布了一些偏差许可来帮助您...

免责声明：查看个人资料

PS：为了避免@Lundin 发表评论，尽管我的专业背景，PC-Lint 并不是分析器的最佳选择。

-- 已编辑--

据此，HAL 符合 MISRA C 2012。

根据（现在添加的）链接

HAL 和 LL API 可用于生产，开发符合 MISRA-C®:2012 指南并使用 CodeSonar 静态分析进行检查 工具。报告可按需提供。

您需要索取这些报告，看看他们怎么说。我很想亲自去问他们......

由于他们声称符合 MISRA C 2012，因此将有一份指南合规摘要（以及其他一些内容）......如果没有，他们就不合规。