问题标签 [misra]

我无法理解以下 misra 规则，“函数不得在块范围内声明”。文档中给出的解释是“在块范围内声明的函数将引用封闭命名空间的成员，因此声明应显式放置在命名空间级别。” 他们的意思是指封闭命名空间的成员？有人可以澄清一下吗？

我正在开发一个 ARM 嵌入式应用程序。我有点陷入一个愚蠢的问题 - 我有一个无符号 8 位整数数组：

它是用一些数据初始化的——初始化算法引入了很多令人困惑且与问题无关的变量，所以我不会在这里重新发布。我在调试器变量 watch 中看到了这个数组，我确定它填充了从 0 到 31 的整数值。

我想取这个数组的任何元素，比如第 15 个，并将其转换为，char*以便它可以显示在我的 LCD 屏幕上。我使用sprintf函数重写它：

请注意：不，我不能使用该stdlib itoa()功能，因为它不符合我必须遵守的 MISRA-C 标准。

结果，我的d缓冲区中只得到一个二进制零值。有任何想法吗？

这个问题可能过于宽泛，或者观点偏颇，但我知道这个网站充满了经验丰富的程序员，我认为它可能会鼓励一个很好的讨论。

我正在用 C 实现一个嵌入式应用程序，其中我使用了一个包含结构的链表：

总的来说它工作得很好，但是在现在的项目中，我正在转向 MISRA-C 编程指南。MISRA 禁止使用任何动态数据结构，因为它可能会在内存有限的嵌入式系统中导致未指定的行为。

我首先想到的当然是一个经典的静态结构数组，具有固定的大小。这个结构体的实例永远不会超过 30 个，而且我们仍然只使用了不到 5% 的可用内存，因此即使没有使用所有这些内存，也不会影响我们的程序性能。像这样：

然而，这种方法有一些困难，例如，有时我需要从列表中删除一个元素，然后它会留下一个空元素，迫使我用一个索引重写所有其他元素。

是否有任何干净、优雅的方式来实现类似于链表的功能，而不使用它们？

我必须说，我在一个看似基本的问题上遇到了相当大的难题。我有一个结构，我想将一个数组存储为一个字段。我想在不同的上下文中重用这个结构，有时我需要一个更大的数组，有时需要一个更小的数组。C 禁止使用可变大小的缓冲区。因此，自然的方法是将指向该数组的指针声明为结构成员：

然而，这种方法的问题是我必须遵守 MISRA-C 的规则，它禁止动态内存分配。那么，如果我想分配内存并初始化数组，我不得不这样做：

这是 MISRA 标准所禁止的。我还能怎么做？

我正在用 C 语言开发一个嵌入式应用程序，它必须符合MISRA标准。它将涉及使用包含波兰符号 (ąęćłńśźż) 的字符串。我尝试使用八进制/十六进制转义序列对它们进行编码：

但这些是规则 4.1 所禁止的。MISRA-C 2004。此规则是必需的。

我的问题是：是否有可能以及如何仅使用 ISO/IEC 9899 的简单转义序列对该字符集进行编码？

我从我们的静态分析工具中收到有关以下代码段的错误：

错误是：

MISRA-2004 违反规则 10.1：隐式转换函数参数中的非常量表达式。将底层类型为“unsigned char”（8 位，无符号）的“值”转换为类型“int”（32 位，有符号）。

MISRA 对“%X”说明符的期望符号和位宽是多少？

据说“%X”unsigned int取自cppreference page。

IAR 编译器的 MISRA C 2004 检查器没有错误。
这个来自 Coverity。

在 Notepad++ 中打开一些遗留代码，并注意到函数注释标题下方出现了一些FF字符。它们是 ASCII 码 12，即换页符。请问FF字符在MISRA C2标准中有效吗？抱歉，我无法使用 PC-Lint/QAC 检查器。

我了解 MISRA-C 标准适用于嵌入式固件。当嵌入式 Linux 是您的产品平台时，您的嵌入式应用程序是否可以/应该被开发为符合 MISRA-C 标准？有没有人考虑过这样的练习？

我的一般感觉是，您必须首先了解所有“规则”，然后在您的设计/编码阶段应用它们。可能存在需要强制合规的系统调用 (pthread_create) 和 void* 等实例 - 生成看起来难看的代码。

我习惯于 Parasoft C++test，我想对代码进行静态分析。代码是在Windriver VxWorksDiab 中用 C++ 开发的。对于为测试配置项目，我使用以下内容：对于 Wind River 项目的直接测试，从 Wind River Workbench 项目中选择使用选项。对于自定义项目（不受 Workbench 管理的项目），您可以尝试使用构建系统选项中的使用选项，该选项基于与Wind River Workbench项目中使用选项相同的机制。

但不是在运行时代码分析，例如 Misra-c++

是什么原因？

在调试一些嵌入式代码时，我遇到了这样的事情：

为什么这个构造会比 (*buffPtr)++ 有所改进？