之前给大家分享过 MISRA C 相关的内容,今天给大家分享一份汽车电子行业的MISRA C标准。
什么是MISRA?MISRA (The Motor Industry Software Reliability Association),中文名称为汽车工业软件可靠性联会,是英国的一个跨国汽车工业协会,其成员包括了大部分欧美汽车生产商。
其核心使命是为汽车工业提供服务和协助,帮助厂方开发安全的、高可靠性的嵌入式软件。MISRA C则是由MISRA提出的针对嵌入式C语言开发标准,目的是提高嵌入式系统的安全性、可读性和可移植性。
MISRA C一开始主要是针对汽车产业,后面他产业也逐渐开始使用MISRA C,包括航天、电信、国防、医疗设备、铁路等领域中都已有厂商使用MISRA C。通常认为,如果能够完全遵守这些标准,则该嵌入式C代码就是易读、可靠、可移植和易于维护的。
因此,很多嵌入式开发者都以MISRA C来衡量自己的编码风格,比如著名的uC/OS就称自己99%的代码遵循MISRA C编码规范标准。
因此,作为嵌入式开发者,不论哪个行业,都应以产品安全性为前提,保证可靠性、可读性、可移植性,也就是保证自身代码尽可能符合MISRA C。
MISRA C应用在越来越多领域,作为嵌入式开发者,编码过程规范应该尽可能遵循MISRA C规则,但也分特殊情况,有的时候为了严格按规范做可能会严重提高工作量或者降低系统性能,此时需要衡量一个平衡点。
关于MISRA C,本人的几点体会。
1)编码过程尽可能遵循MISRA C规范,提高代码可靠性、可读性、可移植。可靠性(稳定性)是前提,可读性、可移植是衡量一个程序员编码水平的因素之一。
特别是对于嵌入式程序员,与硬件相关的编程,考虑到成本、供应链等问题,硬件可能会经常变动或者需要兼容多种硬件,此时,可移植性就体现出优势了,大大减少重复的编码工作。
2)特殊情况下,是可以打破规则的。比如,其中禁止使用goto语句,也是相关标准要求禁止的。有些时候是可以使用的,而且使用其他会使得程序逻辑更清晰。但,如果“特殊情况”出现非常频繁,那就得考虑自身的程序架构是否合理了。
3)可以借助一些工具进行MISRA C检查。如IAR中,就有支持MISRA C规则检查。以下为MISRA C 2004规范标准。
环境规则1.1(强制):所有的代码应该遵守 ISO 9899:1990“Programming Language C”
规则1.2(强制):只有当具备统一接口的目标代码的时候才可以采用多种编译器和语言。
规则1.4(强制):检查编译器 / 连接器以确保支持 31 一个有效字符,支持大小写敏感。
语言扩展Rule 2.1(强制):汇编语言应该封装起来并且隔离。
例如:#define NOP asm( “NOP”)
规则2.2(强制):源代码只能采用 /* … * /风格的注释。
规则2.3(强制):字符序列 /* 不能在注释中使用。
注: C 语言不支持注释的嵌套即使一些编译器支持这个语言扩展。
规则2.4(建议):代码段不能注释掉。
注:应采用 #if 或者#ifdef 来构成一个注释,否则代码里如果有注释会改变代码的作用。
文档化规则3.3(建议):编译器对于整数除法运算的实施应该写入文档。
例:
-5/3 = -1 余-2 有些编译器结果是 -2 于+1。
字符集规则4.1(强制):只能使用 ISO 标准定义的字符集。
标识符规则6.5 (强制):在内部范围的标识符不能和外部的标识符用同样的名字,因为会隐藏那个标识符。例:
int16_t i:
void f()
{
int16_t i;
i=3 ;
}
规则5.2(强制):typedef 名称只能唯一,不能重复定义。
规则5.4(强制):标记名应该是唯一的标识符。
规则5.7(建议):标识符不能重复使用。
类型规则6.1(强制):char 类型只能用来存储使用字符。
规则6.2(强制):signed 和 unsigned char 只能用来存储和使用数据值。
规则6.3(建议):对于基本数据类型,必须使用typedef显式标识出数据长度。
例:
typedef signed char int8_t;
typedef unsigned int uint16_t;
约束规则7.1(强制):禁止使用八进制数(0除外)或者八进制转义字符。
注:整型常数以 0开始会被认为是八进制。例:
code[1]=109
code[2]=100
code[3]=052
如果是对总线消息初始化,会有危险。
声明和定义规则8.1(强制):函数都应该有原型声明,且相对函数定义和调用可见。
规则8.2(强制):无论何时一个对象和函数声明或者定义,它的类型应该明确声明 。
规则8.3(强制):函数声明中的参数类型应该和定义中的类型一致。
规则8.4(强制):如果对象或函数被声明了多次,那么它们的类型应该是兼容的。
规则8.5(强制):头文件中不应定义对象或者函数。
规则8.6(强制):函数应该声明为具有文件作用域。
规则8.7(强制):如果对象的访问只是在单一的函数中,那么对象应该在块范围内声明。
规则8.8(强制):外部变量或者函数只能声明在一个文件中。
规则8.9(强制):具有外部链接的标识符应该具有准确的外部定义。
规则8.10(强制):在文件范围内声明和定义的所有对象或函数具有内部链接,除非是在需要外部链接的情况下。
规则8.11(强制):static存储类标识符应该用于具有内部链接对象和函数的定义和声明。
规则8.12(强制):数组声明为外部,应该明确声明大小或者直接初始化确定。
初始化规则9.1(强制):所有变量在使用之前都应该赋值。
规则9.2(强制):应该使用大括号一指示和匹配数组和结构的非零初始化构造。
规则9.3(强制):在枚举列表中,”=“不能显式用于除首元素之外的元素上,除非所有的元素都是显式初始化的。
数学类型转换(隐式)规则10.1(强制):整型表达式不要隐式转换为其他类型。
1)转换到更大的整型。
2)表达式太复杂。
3)表达式不是常数是一个函数。
4)表达式不是一个常数是一个返回表达式。
规则10.2(强制):浮点数表达式不要隐式转换为其他类型。
1)转换到更大的浮点数。
2)表达式太复杂。
3)表达式是一个函数。
4)表达式是一个返回表达式。
数学类型转换(明确)规则10.3(强制):整型表达式的值只能转换到更窄小且是同样符号类型的表达式。
规则10.4(强制):浮点表达式的值只能转换到更窄小的浮点表达式。
规则10.5(强制):如果位运算~和《《应用在基本类型为unsigned char 或unsigned short的操作数,结果应该立即强制转换为预期操作数的基本类型。例:
uint8_t a = 0x5a;
uint8_t b;
b = ((uint8_t)(~a))》》4;
数学类型转换规则10.6(强制):所有的 unsigned 类型都应该有后缀“U”。
规则11.1(强制):指针不能转换为函数或者整型以外的其他类型。
表达式规则12.2(强制):表达式的值应和标准允许的评估顺序一致。例:
x=b[i] + i++;
不同的编译器给出的结果不一样,b[i] 是否先执行?应:x=b[i];i++;比如:
x=func(i++,i);
规则12.3(强制):sizeof 操作符不能用在包含边界作用(side effect) 的表达式上。例:
int32_t=i;
int32_t=j;
j=sizeof(i=1234);
表达式并没有执行,只是得到表达式类型int的size。
规则12.4(强制):逻辑操作符 && 或者||右边不能包含边界作用 (side effect)。
例:
if(ishight) && (x== i++))
如果 ishight =0 那么 i++不会评估
规则12.5(建议):++和- - 不能和其他表达式用在一个表达式中。
例:
u8a=++u8b + u8c–;
控制语句表达式规则13.1(强制):赋值语句不能用在一个产生布尔值的表达式中。
例:
if((x=y)!=0) …
if (x=y) …
规则13.3(强制):浮点表达式不应该测试其是否相等或者不相等。
规则13.4(强制):for控制表达式中不要包含任何浮点类型。
规则13.6(强制):数字变量作为for循环的循环计数不要在循环体内部被修改。
例:
flag=1;
for(i=0;(i《5)&&(flag==1);i++)
{
flag=0;
i=i+3;
}
控制流规则14.1(强制):不要有执行不到的代码。
例:
swich(event)
{
case 0;
do_wakeup();
break;
do_more();
…
}
规则14.4(强制) :goto 语句不能使用。
规则14.5(强制):continue 不能使用。
规则14.6(强制):函数应在函数结束有一个出口。
规则14.7(强制):witch、while do 、while for 语句体应是一个混合语句。
规则14.10(强制):所有if else if 结构都应该由 else 结束。
switch(x)
{
uint8_t var; /* 违反*/
case 0:
…
}
函数规则16.2(强制):函数不能直接或者间接的调用自己。
例:系统不能用递归,超出堆栈空间很危险。
规则16.8(强制):non-void 类型函数的所有出口路径都应该有一个明确的return 语句表达式。
指针和数组规则17.1(强制):指针的数学运算只能用在指向数组的地址上。
规则17.3(强制):》,》=,《,《= 不能用在指针类型,除非指向同一个数组。
规则17.5(建议):禁止使用 2 级以上指针。
结构和联合规则18.4(强制):禁止使用union(共用体)。
预处理指令规则19.1(建议):#include 语句的前面只能有其他预处理指令和注释。
规则19.2(建议):#include 指令中的头文件名称不能包含非标准的字符。
规则19.5(强制):宏不能在函数体内定义。
规则19.8(强制):类函数宏调用时不能没有它的参数。
标准库规则20.1(强制):标准库中的保留标识符,宏和函数不能定义,重定义和undefined。
规则20.4(强制):动态内存分配不能使用。
例:不能使用malloc、calloc、free、realloc。
规则20.9(强制):输入输出库 (stdio.h) 不能用在产生嵌入式系统中。
规则20.12(强制):时间处理函数 time.h不能使用。
运行时故障规则21.1(强制):通过使用以下手段确保把运行时故障最小化。
1)静态分析工具/技术。
2)动态分析工具/技术。
3)编写明确的代码避免运行时错误。
原文标题:分享一份汽车电子行业的C标准
文章出处:【微信公众号:strongerHuang】欢迎添加关注!文章转载请注明出处。
责任编辑:haq
-
汽车电子
+关注
关注
3024文章
7866浏览量
166487
原文标题:分享一份汽车电子行业的C标准
文章出处:【微信号:strongerHuang,微信公众号:strongerHuang】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论