MISRA C_2012规则翻译、解读、示例

目录

一、MISRA C_2012介绍

二、MISRA C_2012每条规则翻译、解读、示例

Rule 1系列，标准C环境准则

Rule 1.1 程序不应包含任何违反标准C语法和约束的内容，也不应超过实现的转换限制

Rule 1.2 不应使用语言扩展

Rule 1.3 不应出现未定义或关键的未指定行为

Rule 2系列，未使用的代码的处理

---

一、MISRA C_2012介绍

先摘录一段百度百科里的说法：

MISRA C是由汽车产业软件可靠性协会（MISRA）提出的C语言开发标准。其目的是在增进嵌入式系统的安全性及可移植性。针对C++语言也有对应的标准MISRA C++。

MISRA C一开始主要是针对汽车产业，不过其他产业也逐渐开始使用MISRA C：包括航天、电信、国防、医疗设备、铁路等领域中都已有厂商使用MISRA C。

MISRA C的第一版《Guidelines for the use of the C language in vehicle based software》是在1998年发行，一般称为MISRA-C:1998.。MISRA-C:1998有127项规则，规则从1号编号到127号，其中有93项是强制要求，其余的34项是推荐使用的规则。

在2004年时发行了第二版的MISRA C的第一版《Guidelines for the use of the C language in critical systems》（或称作MISRA-C:2004），其中有许多重要建议事项的变更，其规则也重新编号。MISRA-C:2004有141项规则，其中121项是强制要求，其余的20项是推荐使用的规则。规则分为21类，从“开发环境”到“运行期错误”。

2012年发布第三版，为当前最新有效的C语言规范版本，称为MISRAC:2012。 

MISRA版本	发布年份	C语言版本	指令 数量	规则 数量	指南 总数
1998	1998	C90	不详	127	不详
2004	2004	C90	不详	142	不详
2012	2012	C99	16	143	159
2012 AMD-1	2016	C99	17	156	173
2012 AMD-2	2020	C11	17	158	175

Misra C不能100%保证程序不出问题，但是能尽可能的预防，总结一下，基本上使用Misra C具有以下五个维度的优势：

• 提升可靠性
• 提升可读性
• 提升可移植性
• 提升可维护性
• 提升安全性

若要保证我们的程序能符合Misra C编码规范，一方面是在开发初期写代码的时候尽量按照Misra C规范来写，一方面是在后期通过一些代码检测工具来检测我们的代码是否符合Misra C规范。

因此我们平时要多积累一些Misra C规范的约束经验，尽量在后期检测中少出一些问题，毕竟出了问题还要花时间来重新翻规范重新改。

二、MISRA C_2012每条规则翻译、解读、示例

在这里我只翻译和解读158条规则，一些重要的规则尽量给出正确的示例，个人能力有限，因此不保证翻译的准确性，主要还是用于自己能更加的熟悉规则，能直接开发出符合规范的代码，当然，这个工作不是一天能完成的，反正我有空就会在这里更新的。

Rule 1系列，标准C环境准则

---

Rule 1.1 程序不应包含任何违反标准C语法和约束的内容，也不应超过实现的转换限制

• 原文：Rule 1.1  The program shall contain no violations  of the standard C syntax and constraints, and shall not exceed the implementation’s tr anslation limits
• 级别：低
• 解读：程序只能使用C语言及其库中所选标准版本中指定的特性
• 示例：比如你用C90的编译器你就要符合C90的规则和特性，而不能去使用到C11的特性，其实即使你使用了，编译器也不支持，但不一定都能检测出来，具有一定的风险

Rule 1.2 不应使用语言扩展

• 原文：Rule 1.2  Language extensions should not be used
• 级别：低
• 解读：不要用编程语言扩展属性，否则会降低程序的可移植性
• 示例：无

Rule 1.3 不应出现未定义或关键的未指定行为

• 原文：Rule 1.3  There shall be no occurrence of undefi ned or critical unspecified behaviour
• 级别：中
• 解读：

任何引起未定义或未指定行为的程序都可能不以预期的方式运行。在许多情况下，这样做的结果是使程序不可移植，但也可能发生更严重的问题。例如，未定义的行为可能会影响计算的结果。如果软件的正确操作依赖于这个计算，那么系统安全可能会受到损害。如果未定义的行为只在很少的情况下出现，那么这个问题就特别难以检测。许多MISRA C指南的设计都是为了避免某些未定义和未明确的行为。例如，对规则11.4、规则11.8和规则19.2的遵守确保了在C语言中不可能创建一个非const限定的指针，该指针指向用const限定类型声明的对象。这避免了C90 Undefined 391和C99 Undefined 61。

• 示例：英文原版pdf的附录H列出了所有未定义和关键的未指定行为，以及MISRA C防止它们发生的指南。

Rule 2系列，未使用的代码的处理

---

Rule 2.1 项目不应该包含运行不到的代码

• 原文：Rule 2.1  A project shall not contain unreachable code
• 级别：高
• 解读：如果一个程序没有表现出任何未定义的行为，那么无法到达的代码就不能被执行，也不能对程序的输出产生任何影响。因此，无法到达的代码的存在可能表明程序逻辑中的错误。  无法到达的代码会占用目标机器的内存空间，可能会导致编译器在围绕无法到达的代码传输控制时选择更长的、更慢的跳转指令。而且在循环中，它可以防止整个循环驻留在指令缓存中。
• 示例：switch中某个case分支是永远运行不到的，程序员应该删除这种代码。

Rule 2.2 项目不应该包含死代码

• 原文：Rule 2.2  There shall be no dead code
• 级别：高
• 解读：任何可以删除掉但是不影响程序正常运行的代码都是无效代码，由于无效代码可能被编译器删除，所以它的存在可能会引起混乱。
• 示例：类似以下这种的程序永远运行不到的代码都叫无效代码。

if(0)
{
    function();
}

Rule 2.3 项目不应该包含未使用的类型声明

• 原文：Rule 2.3  A project  should not contain unused ty pe declarations
• 级别：低
• 解读：如果声明了类型但没有使用，那么审阅者就不清楚该类型是冗余的还是错误地未使用。
• 示例：使用typedef定义了一个数据类型但是从未使用过。

typedef int local_type;  /* 从未使用的话将违反规则 */

Rule 2.4 项目不应该包含未使用的标签声明

• 原文：Rule 2.4  A project should not contain unused ta g declarations
• 级别：低
• 解读：如果一个标签已经声明但没有使用，那么审阅者就不清楚这个标签是多余的还是错误地没有使用。
• 示例：使用typedef定义了一个结构体类型标签或者使用enum定义了一个enum类型标签但是都从未使用过。

enum state { S_init, S_run, S_sleep };   /* 从未使用state标签的话将违反规则 */

typedef struct record_t  /* 从未使用record_t标签的话将违反规则 */
{
  uint16_t  key;
  uint16_t  val;
} record1_t;

typedef struct  /* 这种是可以的，不会违反规则 */
{
  uint16_t  key;
  uint16_t  val;
} record2_t;