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;

 

 

 

 

 

 

 

 

 

 

 

 

 

你可能感兴趣的:(嵌入式,misra)