MISRAC规范学习分析
misra c++编号规则

misra c++编号规则
MISRA C++ (MISRA C++:2008) 是一种针对C++ 编程语言的软件开发规范,旨在提高代码的可读性、可维护性和可靠性。
MISRA C++ 包含一系列规则,下面是一些常见的MISRA C++ 编号规则示例:
1. 规则2-1-1:禁止使用C 语言风格的强制类型转换。
2. 规则3-1-1:不允许使用多个返回语句。
3. 规则5-0-1:禁止使用C 语言风格的字符串操作函数。
4. 规则5-2-2:确保容器类的size() 函数返回无符号整数类型。
5. 规则8-0-1:不允许在头文件中定义非内联函数。
6. 规则14-0-1:确保每个函数都有明确的返回语句。
这些规则是为了遵循良好的编程实践和减少代码的潜在错误,但具体的规则数量和内容可能因不同版本的MISRA C++ 规范而有所不同。
在实际开发中,开发人员可以根据规范选择性地遵循相应的规则,并结合工具和代码审查等方法来确保代码符合MISRA C++ 规范的要求。
需要注意的是,MISRA C++ 规范是一种指导性的规范,可以帮助开发人员编写高质量、可靠的C++ 代码,但它并不适用于所有项目和情况。
在实际使用中,应根据项目需求和团队约定来决定是否采用MISRA C++ 规范以及具体遵循哪些规则。
misra c 2012 rule 20.7 解析 -回复

misra c 2012 rule 20.7 解析-回复Misra C 2012规则20.7主要涉及禁止使用带有不匹配类型信息的参数(参数传递),并提出了一系列相关要求和建议。
本文将逐步解析该规则,从其背景、目的、规则内容、实施方法等方面进行详细阐述。
一、背景和目的在C语言编程中,函数参数传递是常见的操作。
参数的类型信息对于编译器在编译和链接期间进行类型检查和匹配非常重要。
然而,在某些情况下,可能会存在参数传递中类型信息不匹配的问题,这会引发潜在的错误和不确定行为。
为了避免这种情况的发生,Misra C 2012规则20.7被提出。
该规则的目的是通过明确禁止使用不匹配类型信息的参数,以减少由此产生的潜在错误和不确定性,提高代码的可靠性和可维护性。
二、规则内容Misra C 2012规则20.7的具体内容包括以下几点:1. 禁止使用参数传递时类型信息不匹配的情况。
2. 禁止使用任何具有指针类型的参数来绕过类型匹配。
这些禁止使用的情况包括但不限于以下情形:1. 可调用函数与原型不匹配,例如类型不同的参数传递。
2. 使用强制类型转换来绕过类型匹配。
3. 在函数指针中传递类型不匹配的参数。
三、实施方法为了遵守Misra C 2012规则20.7,开发人员可以采取以下几个实施方法:1. 确保传递给函数的参数与函数原型中的参数类型完全匹配,包括类型和数量。
2. 避免使用强制类型转换来解决参数类型不匹配的问题,而是采用合适的数据类型或优化函数设计。
3. 尽量避免使用函数指针中传递类型不匹配的参数,如果必须使用,应当仔细考虑类型转换的合理性和安全性。
此外,对于不匹配类型信息的参数,可以考虑使用其他合理的方法来替代,如结构体、联合体等。
四、规则的优点与挑战Misra C 2012规则20.7的实施有助于提高代码的可靠性和可维护性,减少由于参数传递中类型信息不匹配引起的错误和不确定性。
遵守该规则可以帮助开发人员在编译和链接期间及时发现潜在的类型不匹配错误,减少后期调试和维护成本。
misra c 中 cmn规则

misra c 中 cmn规则Misra C是一种针对嵌入式C语言编程的软件开发规范。
其中的CMN 规则(Common)是其中的一部分规则,本文将对CMN规则进行详细介绍。
CMN规则主要关注代码的可读性和可维护性,以提高软件的质量和可靠性。
它包括了一系列的编程指南,涵盖了变量命名、注释、代码结构等方面。
CMN规则要求使用有意义的变量命名。
变量名应该能够准确地描述其含义,避免使用无意义的简写或缩写。
此外,变量名应该使用小写字母和下划线,并且遵循统一的命名风格。
CMN规则强调了注释的重要性。
注释应该清晰明了地描述代码的功能、用途和实现细节。
注释应该放在代码的关键部分,以帮助其他开发人员理解代码的逻辑。
注释也应该及时更新,以反映代码的变化。
CMN规则要求避免使用复杂的表达式和语句。
代码应该简洁明了,避免使用过多的嵌套和条件判断。
复杂的代码不仅难以理解,还容易引入错误。
CMN规则强调了代码的结构化。
代码应该按照逻辑分块,使用恰当的缩进和空行,以提高代码的可读性。
代码块应该有明确的开始和结束标记,避免出现悬挂的if语句或循环。
CMN规则要求避免使用全局变量。
全局变量会增加代码的复杂性和不确定性,容易引发意外的副作用。
相反,应该尽量使用局部变量和函数参数来传递数据。
CMN规则强调了错误处理的重要性。
代码应该有适当的错误处理机制,以应对可能出现的异常情况。
错误处理应该包括错误码、错误消息和适当的恢复措施。
CMN规则要求避免使用浮点数和浮点数运算。
浮点数在嵌入式系统中的精度和性能都受到限制,容易引发不确定性和错误。
相反,应该尽量使用整数和固定点数来代替。
CMN规则强调了代码的可移植性。
代码应该尽量避免使用与平台相关的特性和函数。
如果必须使用,应该有相应的兼容性处理。
CMN规则要求避免使用goto语句。
goto语句容易引发代码的混乱和不可控,增加代码的复杂性。
相反,应该使用结构化的控制语句,如if语句和循环语句。
misrac2012规则

misrac2012规则MISRA C:2012规则概述引言MISRA C:2012规则是一套用于C语言编程的软件开发规范,旨在提高C语言代码的可靠性、可维护性和可移植性。
本文将详细介绍MISRA C:2012规则的主要内容和要求。
1. 规则1:源文件MISRA C:2012规则要求每个源文件应该是一个完整的、独立的模块,其内容应该尽可能简洁、清晰。
每个源文件应该包含一个独立的头文件,用于声明全局变量和函数原型。
2. 规则2:注释MISRA C:2012规则要求在代码中添加注释来解释代码的意图和功能。
注释应该清晰、简洁,并且应该放置在代码之前而不是代码之后。
3. 规则3:标识符命名MISRA C:2012规则要求标识符的命名应该具有描述性,并且应该遵循统一的命名风格。
标识符应该使用小写字母和下划线,不应该使用数字或特殊字符作为开头。
4. 规则4:变量声明MISRA C:2012规则要求所有变量在使用之前必须先声明。
变量的声明应该放置在函数的开头,并且应该尽量避免全局变量的使用。
5. 规则5:控制流MISRA C:2012规则要求控制流语句(如if语句和switch语句)必须有明确的结束条件,并且不允许出现没有意义的代码。
控制流语句的嵌套层数应该尽量减少,以提高代码的可读性。
6. 规则6:循环和迭代MISRA C:2012规则要求循环和迭代语句(如for循环和while循环)应该有明确的结束条件,并且循环变量的作用范围应该尽可能小。
7. 规则7:函数MISRA C:2012规则要求函数的参数和返回值应该有明确的类型和语义。
函数的参数应该尽量避免使用全局变量,并且函数的实现应该尽可能简洁、清晰。
8. 规则8:指针MISRA C:2012规则要求指针的使用应该谨慎,并且应该遵循一定的安全性规范。
指针的解引用操作应该在使用之前进行非空判断,以避免空指针引发的异常。
9. 规则9:内存管理MISRA C:2012规则要求在动态内存分配和释放过程中应该遵循一定的规范和约束,以避免内存泄漏和内存访问错误。
qac的misrac屏蔽检查规则

qac的misrac屏蔽检查规则MISRA-C是一套针对嵌入式C语言编程的软件开发标准,由Motor Industry Software Reliability Association(MISRA)制定。
MISRA-C旨在提高嵌入式系统软件的可靠性、安全性和可维护性,遵守MISRA-C标准可以帮助开发人员避免一些常见的编程错误和风险。
其中,MISRA-C:2012是最新的版本,对于C语言的编写规范做出了一系列的规定。
在MISRA-C:2012标准中,有一条规则是关于MISRA-C的MISRA-C规则15.5的屏蔽检查规则。
根据该规则,程序员在编写代码时可以对MISRA规则进行屏蔽,即暂时忽略某些规则的检查,但是需要在代码中明确注释说明。
在进行MISRA-C规则的屏蔽检查时,有一些需要注意的地方。
首先,需要保证规则的屏蔽是有明确的理由的,例如某些规则可能会因为特定的硬件平台、特定的需求或者特殊的设计模式而无法遵守。
其次,在屏蔽规则时,应该避免屏蔽整个文件的所有规则,而是针对具体的代码片段进行屏蔽。
这样做可以在最大程度上减少屏蔽规则的范围,避免对其他部分代码的影响。
在屏蔽规则时,应该使用适当的注释来说明屏蔽的原因和范围。
注释应该明确地指出哪个规则被屏蔽了,为什么屏蔽了,以及屏蔽的时间范围。
这样的注释可以帮助其他开发人员了解代码中的规则屏蔽,避免误解和潜在的问题。
在屏蔽规则时,应该避免在整个项目中广泛使用屏蔽规则,因为这可能导致代码质量的下降和潜在的风险增加。
屏蔽规则应该被视为一种例外情况,只有在确实无法遵守规则的情况下才应该使用。
MISRA-C的MISRA规则的屏蔽检查规则是一种有益的工具,可以在一定程度上灵活应对特定的编程场景和需求。
然而,开发人员在屏蔽规则时需要保持谨慎,并且在注释中清楚地解释屏蔽规则的原因和范围。
同时,应该避免滥用屏蔽规则,保持代码的质量和可维护性。
总之,MISRA-C的MISRA规则15.5的屏蔽检查规则在开发嵌入式系统软件时具有一定的灵活性和实用性。
pclint misra c 标准的要求 -回复

pclint misra c 标准的要求-回复PCLint是一款静态代码分析工具,常用于C语言和C++代码的检查。
而MISRA C是一套C语言编程规范,它旨在提高软件质量、可靠性与可维护性。
本文将探讨PCLint在MISRA C标准中的要求,并详细介绍如何使用PCLint进行MISRA C规范的静态代码检查。
1. MISRA C标准简介MISRA C是由Motor Industry Software Reliability Association (MISRA)制定的一套面向嵌入式系统的C语言编程规范。
它旨在改善编码质量、提高软件的可靠性和可维护性,规范了C语言的语法和编码风格。
2. PCLint介绍PCLint是由Gimpel Software开发的C/C++静态代码分析工具。
它能够检查代码中的潜在问题和编程错误,并生成详细的报告,指导开发人员进行代码质量的改进。
3. PCLint与MISRA C规范的结合PCLint提供了针对MISRA C规范的专门配置文件,并能够对代码进行准确的静态分析。
通过使用PCLint的MISRA C配置文件,可以更容易地检查代码是否符合MISRA C标准中的要求。
4. PCLint对MISRA C规范的主要要求- 命名规则:变量、函数和宏的命名必须符合特定规范,如使用小写字母和下划线。
- 语法要求:代码必须符合MISRA C提出的语法规则,如禁止使用某些语言特性和语法结构。
- 数据类型:确保使用符合要求的数据类型,并禁止使用不安全的类型转换。
- 注释和文档:代码必须进行适当的注释,以提高代码的可读性和可维护性。
- 错误处理:对于可能发生错误的操作,必须进行适当的错误处理,如检查返回值和处理异常。
- 代码复杂性:代码的复杂性必须控制在合理的范围内,以确保代码的清晰性和可理解性。
- 嵌入式编程相关:对于嵌入式系统开发,还有一些特定的规范要求,如中断处理、内存管理等。
5. 使用PCLint进行MISRA C规范检查的步骤- 配置PCLint环境:下载和安装PCLint,并获取最新的MISRA C配置文件。
misra-c 解读 -回复

misra-c 解读-回复[Misrac 解读] 是一种软件安全工程标准,旨在规范C编程语言的使用,以提高软件的可靠性和安全性。
Misrac(Motor Industry Software Reliability Association C)由汽车工业的软件开发专家组成的组织于1994年成立。
他们致力于解决汽车电子系统中的软件可靠性和安全性问题。
Misrac标准的目标是提供一套能够降低软件开发中存在的缺陷风险的指导原则。
这些原则主要包括了C编码规范、代码风格和编程实践等方面。
此外,Misrac标准还提供了一些软件工具来实现标准的检查和自动化,以确保开发人员能够遵守Misrac标准。
Misrac标准的内容相对详细和全面,涵盖了C语言中的许多特殊情况和编码规范。
根据Misrac标准,C编程应该遵循以下主要原则:1. 可移植性:Misrac标准强调编写可移植的代码,以便能够在不同的平台上运行。
这种可移植性是通过避免使用不可移植的功能和特性来实现的。
2. 确定性:Misrac标准鼓励编写确定性的代码,以确保代码在不受外界环境变化的情况下具有可预测的行为。
这要求编写代码时避免使用不确定的行为和依赖于底层实现的特性。
3. 可读性和可维护性:Misrac标准强调编写易于阅读和维护的代码。
它提供了一些规范和建议,如变量命名、代码布局、注释等,以提高代码的可读性和可维护性。
4. 安全性:Misrac标准重视编写安全的代码,以防止潜在的安全漏洞和攻击。
它提供了一些代码规范和最佳实践,如避免缓冲区溢出、使用安全的字符串处理函数等。
Misrac标准在汽车行业得到广泛应用,特别是在汽车电子系统的软件开发过程中。
这是因为汽车电子系统对软件可靠性和安全性有较高的要求,任何软件缺陷或漏洞可能导致严重的后果,如汽车故障或安全事故。
遵循Misrac标准有许多好处。
首先,它可以提高软件的质量和可靠性,减少软件缺陷和故障的概率。
其次,它可以提高软件开发过程的效率和一致性,使不同开发人员之间的代码风格和质量有更高的一致性。
MISRA C++新规范改善高安全性要求控制系统

5 软件设计 5 . 1 系统主程序流程
系统内部具有双核 ,每个内核单独执行程序 。主程序 流程如图 9 所示 。
图 9 系统主程序流程
5 . 2 双核通信流程
双核通信采用读忙线 发送 、中断 接收的 方式 ,增 强了 数据发送的可靠性 ,如图 10 所示 。
HT7937 提 供 高输 出电 压 ,驱 动高 达 5 颗 串 联式 L ED。 采用串联式设计 ,可以让 流经每 颗 L ED 的电 流相 同 ,达到每 颗 L ED 亮 度 相 同 的 目 的 。回 授 电 压 为 95 mV ,借 由 连 接 4. 7 Ω对地的电阻 ,可 以设定 流经 L ED 的电 流为 20 mA。内 建过电压保护功能 ,在 L ED 损坏 造成回 授路 径开 路时 ,将输 出电压 限 制 于 保 护 电 压 之 下 , 进 一 步 保 护 IC 不 会 烧 毁 。 HT7937 操作在 1. 2 M Hz 的工 作频率 ,能让设 计者使 用小电 感电容值的外部组件 ,降低外部组 件占 PCB 的面 积 。搭配小 型化封装 SOT26 ,适合 用于各式可携 式产品 ,如手 机 、数字相 机 、音乐/ 多媒体播放器等 。
(收稿日期 : 2008207223)
MISRA C + + 新规范改善高 安全性要求控制系统
MISRA C + + 2008 已于今年 6 月 5 号由设在英国的 MISRA (汽车工业软件安全性协会) 发布。MISRA 成立于 1994 年 ,后来 发布了“MISRA C 1998”,指明了标准 C 语言规范 ———ANSI C 中 的 127 处不安全隐患 ,2004 年又发布的 MISRA C 2004 ,将隐患数 目增加到 141 处。从最初定位于汽车相关软件安全性 ,到铁路、 军事、航空 、医疗和对安全性有苛刻要求的系统 ,得到了越来越多 的软件开发工程师的认同 ,以及越来越多的软件编译器开发商的 支持 ,成为相关行业的编程规范或标准 。鉴于 MISRA C 的成功 , MISRA 于 2005 年 9 月底成立了 C + + 专家工作组 ,最新发布的 MISRA C + + 2008 代表了这几年 MISRA 专注研究的成果 。旨 在利用类似于 MISRA C 中使用的技术 ,来建立适合在安全性要 求苛刻的系统中使用的 C + + 的子集 。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
学习MISRAC秦小斌编者按:C语言是开发嵌入式应用的主要工具,然而C语言并非是专门为嵌入式系统设计,相当多的嵌入式系统较一般计算机系统对软件安全性有更苛刻的要求。
1998 年,MISRA指出,一些在C看来可以接受,却存在安全隐患的地方有127处之多。
2004年,MISRA对C的限制增加到141条。
嵌入式系统应用工程师借用计算机专家创建的C语言,使嵌入式系统应用得以飞速发展,而MISRAC是嵌入式系统应用工程师对C语言嵌入式应用做出的贡献。
如今MISRA C已经被越来越多的企业接受,成为用于嵌入式系统的C语言标准,特别是对安全性要求极高的嵌入式系统,软件应符合MISRA标准。
本文将分6讲,与读者共同学习MISRAC。
第一讲:“‘安全第一’的C语言编程规范”,简述MISRAC的概况。
第二讲:“跨越数据类型的重重陷阱”,介绍规范的数据定义和操作方式,重点在隐式数据类型转换中的问题。
第三讲:“指针、结构体、联合体的安全规范”,解析如何安全而高效地应用指针、结构体和联合体。
第四讲:“防范表达式的失控”,剖析MISRAC中关于表达式、函数声明和定义等的不良使用习惯,最大限度地减小各类潜在错误。
第五讲:“准确的程序流控制”,表述C语言中控制表达式和程序流控制的规范做法。
第六讲:“构建安全的编译环境”,讲解与编译器相关的规范编写方式,避免来自编译器的隐患。
学习MISRAC之一:“安全第一”的C语言编程规范C/C++语言无疑是当今嵌入式开发中最为常见的语言。
早期的嵌入式程序大都是用汇编语言开发的,但人们很快就意识到汇编语言所带来的问题——难移植、难复用、难维护和可读性极差。
很多程序会因为当初开发人员的离开而必须重新编写,许多程序员甚至连他们自己几个月前写成的代码都看不懂。
C/C+ +语言恰恰可以解决这些问题。
作为一种相对“低级”的高级语言,C/C++语言能够让嵌入式程序员更自由地控制底层硬件,同时享受高级语言带来的便利。
对于C语言和C++语言,很多的程序员会选择C语言,而避开庞大复杂的C++语言。
这是很容易理解的——C语言写成的代码量比C++语言的更小些,执行效率也更高。
对于程序员来说,能工作的代码并不等于“好”的代码。
“好”代码的指标很多,包括易读、易维护、易移植和可靠等。
其中,可靠性对嵌入式系统非常重要,尤其是在那些对安全性要求很高的系统中,如飞行器、汽车和工业控制中。
这些系统的特点是:只要工作稍有偏差,就有可能造成重大损失或者人员伤亡。
一个不容易出错的系统,除了要有很好的硬件设计(如电磁兼容性),还要有很健壮或者说“安全”的程序。
然而,很少有程序员知道什么样的程序是安全的程序。
很多程序只是表面上可以干活,还存在着大量的隐患。
当然,这其中也有C语言自身的原因。
因为C语言是一门难以掌握的语言,其灵活的编程方式和语法规则对于一个新手来说很可能会成为机关重重的陷阱。
同时,C语言的定义还并不完全,即使是国际通用的C语言标准,也还存在着很多未完全定义的地方。
要求所有的嵌入式程序员都成为C语言专家,避开所有可能带来危险的编程方式,是不现实的。
最好的方法是有一个针对安全性的C语言编程规范,告诉程序员该如何做。
1 MISRAC规范1994年,在英国成立了一个叫做汽车工业软件可靠性联合会(The Motor Industry Software Reliability Association,以下简称MISRA)的组织。
它是致力于协助汽车厂商开发安全可靠的软件的跨国协会,其成员包括:AB汽车电子、罗孚汽车、宾利汽车、福特汽车、捷豹汽车、路虎公司、Lotus公司、MIRA公司、Ricardo公司、TRW 汽车电子、利兹大学和福特VISTEON汽车系统公司。
经过了四年的研究和准备,MISRA于1998年发布了一个针对汽车工业软件安全性的C语言编程规范——《汽车专用软件的C语言编程指南》(Guidelines for the Use of the C Language in Vehicle Based Software),共有127条规则,称为MISRAC:1998。
C语言并不乏国际标准。
国际标准化组织(International Organization of Standardization,简称ISO)的“标准C语言”经历了从C90、C96到C99的变动。
但是,嵌入式程序员很难将ISO标准当作编写安全代码的规范。
一是因为标准C语言并不是针对代码安全的,也并不是专门为嵌入式应用设计的;二是因为“标准C语言”太庞大了,很难操作。
MISRAC: 1998规范的产生恰恰弥补了这方面的空白。
随着很多汽车厂商开始接受MISRAC编程规范,MISRAC:1998也成为汽车工业中最为著名的有关安全性的C语言规范。
2004年,MISRA出版了该规范的新版本——MISRAC:2004。
在新版本中,还将面向的对象由汽车工业扩大到所有的高安全性要求(Critical)系统。
在MISRAC:2004中,共有强制规则121条,推荐规则20条,并删除了15条旧规则。
任何符合MISRAC:2004编程规范的代码都应该严格的遵循121条强制规则的要求,并应该在条件允许的情况下尽可能符合20条推荐规则。
MISRAC:2004将其141条规则分为21个类别,每一条规则对应一条编程准则。
详细情况如表1所列。
04规则分类表1 MISRAC:20最初,MISRAC:1998编程规范的建立是为了增强汽车工业软件的安全性。
可能造成汽车事故的原因有很多,如图1所示,设计和制造时埋下的隐患约占总数的15%,其中也包括软件的设计和制造。
MISRAC:1998就是为了减小这部分隐患而制定的。
MISRAC编程规范的推出迎合了很多汽车厂商的需要,因为一旦厂商在程序设计上出现了问题,用来补救的费用将相当可观。
1999年7月22 日,通用汽车公司(General Motors)就曾经因为其软件设计上的一个问题,被迫召回350万辆已经出厂的汽车,损失之大可想而知。
MISRAC规范不仅在汽车工业开始普及,也同时影响到了嵌入式开发的其他方向。
嵌入式实时操作系统μC/OSII的2.52版本虽然已经于2000年通过了美国航空管理局(FAA)的安全认证,但2003年作者就根据MISRAC:1998规范又对源码做了相应的修改,如将if ((pevent->OSEventTbl[y] &= ~bitx) == 0) {/*… */}的写法,改写成pevent->OSEventTbl[y] &= ~bitx;if (pevent->OSEventTbl[y] == 0) {/*… */}发布了2.62的新版本,并宣称其源代码99%符合MISRAC:1998规范。
一个程序能够符合MISRAC编程规范,不仅需要程序员按照规范编程,编译器也需要对所编译的代码进行规则检查。
现在,很多编译器开发商都对MISRAC规范有了支持,比如IAR的编译器就提供了对MISRAC:1998规范127条规则的检查功能。
2 MISRAC对安全性的理解MISRAC:2004的专家们大都来自于软件工业或者汽车工业的知名公司,规范的制定不仅仅像过去一样局限于汽车工业的C语言编程,同时还涵盖了其他高安全性系统。
图1 汽车事故原因分布图MISRAC:2004认为C程序设计中存在的风险可能由5个方面造成:程序员的失误、程序员对语言的误解、程序员对编译器的误解、编译器的错误和运行出错(runtime errors)。
程序员的失误是司空见惯的。
程序员是人,难免会犯错误。
很多由程序员犯下的错误可以被编译器及时地纠正(如键入错误的变量名等),但也有很多会逃过编译器的检查。
相信任何一个程序员都曾经犯过将“= =”误写成“=”的错误,编译器可能不会认为if(x=y)是一个程序员的失误。
再举个例子,大家都知道++运算符。
假如有下面的指令:i=3;printf(“%d”,++i);输出应该是多少?如果是:printf(“%d”,i++);呢?如果改成-i++呢?i+++i呢?i+++++i呢?绝大多数程序员恐怕已经糊涂了。
在MISRAC:2004中,会明确指出++或--运算符不得和其他运算符混合使用。
C语言非常灵活,它给了程序员非常大的自由。
但事情有好有坏,自由越大,犯错误的机会也就越多。
如果说有些错误是程序员无心之失的话,那么因为程序员对C语言本身或是编译器特性的误解而造成的错误就是“明”知故犯了。
C语言有一些概念很难掌握,非常容易造成误解,如表达式的计算。
请看下面这条语句:if ( ishigh && (x == i++))很多程序员认为执行了这条指令后,i变量的值就会自动加1。
但真正的情况如何呢?MISRA中有一条规则:逻辑运算符&&或||的右操作数不得带有副作用(side effect)*,就是为了避免这种情况下可能出现的问题。
*所谓带有副作用,就是指执行某条语句时会改变运行环境,如执行x=i++之后,i的值会发生变化。
另外,不同编译器对同一语句的处理可能是不一样的。
例如整型变量的长度,不同编译器的规定就不同。
这就要求程序员不仅要清楚C语言本身的特性,还要了解所用的编译器,难度很大。
还有些错误是由编译器(或者说是编写编译器的程序员)本身造成的。
这些错误往往较难发现,有可能会一直存留在最后的程序中。
运行错误指的是那些在运行时出现的错误,如除数等于零、指针地址无效等问题。
运行错误在语法检查时一般无法发现,但一旦发生很可能导致系统崩溃。
例如:#define NULL 0……char* p;p=NULL;printf(“Location of 0 is %d\n”, *p);语法上没有任何问题,但在某些系统上却可能运行出错。
C语言可以产生非常紧凑、高效的代码,一个原因就是C语言提供的运行错误检查功能很少,虽然运行效率得以提高,但也降低了系统的安全性。
有句话说得好,“正确的观念重于一切”。
MISRAC规范对于嵌入式程序员来讲,一个很重要的意义就是提供给他们一些建议,让他们逐渐树立一些好的编程习惯和编程思路,慢慢摒弃那些可能存在风险的编程行为,编写出更为安全、健壮的代码。
比如,很多嵌入式程序员都会忽略注释的重要性,但这样的做法会降低程序的可读性,也会给将来的维护和移植带来风险。
嵌入式程序员经常要接触到各种的编译器,而很多C程序在不同编译器下的处理是不一样的。
MISRAC:2004有一条强制规则,要求程序员把所有和编译器特性相关的C语言行为记录下来。
这样在程序员做移植工作时,风险就降低了。
3 MISRAC的负面效应程序员可能会担心采用MISRAC:2004规范会对他们的程序有负面影响,比如可能会影响代码量、执行效率和程序可读性等。