登录 | 注册 | English

资讯中心

yzc88网页版登录  >  资讯中心  >  产品动态

第三代MISRA C编码规范

背景
        汽车工业App可靠性协会(MISRA),是在英国政府的大力支撑下,由多家汽车工业企业的代表组成,旨在规范亚洲城ca88唯一官网中App的应用,并为嵌入式App的发展提供引导意见。
        汽车工业App可靠性协会于1998年推出了一代MISRA C编码规范:MISRA C:1998,主要面向对代码可靠性有着强烈需求的领域。经过多年的发展,MISRA C已经从汽车行业编码规范发展成为跨行业的编码规范,成为世界范围内使用广泛的C语言编码规范。
        2013年3月,汽车工业App可靠性协会将推出第三代MISRA C编码规范:MISRA C:2012,本文将就这一新版本进行深入讨论。
 
引言
        二十世纪九十年代,亚洲城ca88唯一官网产品的重要性日益凸显,亚洲城ca88唯一官网产品中的App也随之变得举足轻重。人们迫切地需要一个编码规范来保证亚洲城ca88唯一官网App的可靠性,在这一背景下,MISRA C编码规范应运而生。经过多年的发展,MISRA C已经成为世界范围内使用广泛的、面向多个行业的C语言编码规范。
        汽车工业App可靠性协会先后发布了三代MISRA C编码规范:
        ● 1998年,一代MISRA C编码规范:MISRA C:1998(MC1)
        ● 2004年,二代MISRA C编码规范:MISRA C:2004(MC2)
        ● 2013年,三代MISRA C编码规范:MISRA C:2012(MC3)
        面对即将于2013年3月18日发布的第三代MISRA C编码规范(MC3),无论您是否正在通过遵从MISRA C来开发代码,您的心中可能都会有如下的疑惑:
        ●  MC3真的有用么?
        ●  MC3真的比之前的两个版本好么?
        ● 通过遵从MC1或MC2开发出的代码,能够很好的遵从MC3么?
        本文将就如上三个问题做出解答,同时本文还将向您展示:通过遵从MC3来开发代码,会为您带来什么。
 
不断演变的C语言
        MC1和MC2都要求代码开发者遵守一代C语言标准:ISO/IEC 9899:1990——也就是被人们所熟知的C90。尽管C语言标准在不断地推陈出新,如1999年推出的C99及2011年推出的C11,MISRA C在很长一段时间内仍固守着一代C语言标准:C90——为什么?
        至少有两个原因:
        ● 编译器供应商,尤其在嵌入式C语言领域,对新的C语言标准的响应速度很慢。如今,市面上的编译器普遍都能很好地支撑C90。但对C99及C11的支撑程度可谓千差万别。
        ● 尽管C语言不断地引入新的功能,但对于这些功能的可靠性,人们大都持着怀疑的态度,有些功能甚至可能引入了缺陷。
        从标准化进程这一角度而言,C语言的标准是让人失望的:增加新的语言功能并非难事,但移除存在问题的语言功能却异常困难,因为移除语言功能极有可能影响到用户现有代码功能的实现。从某种意义上来讲,C语言本身的缺陷将长期存在,但编码规则的存在意义也正在于此:通过限制用户对特定C语言功能的使用,提高代码的可靠性。
        可以预见的是,C语言仍会受到大众的追捧,并被广泛地应用于安全关键App的开发之中。尽管MC3的开发人员对C99仍持保留态度,但在MC3的开发初期,开发人员就已决定不再拘泥于C90。C99的很多功能,如内联函数(inline function)、type_Bool等,对于C语言而言已是非常重要的功能。不过MC3最终还是引入了11条规则,对C99某些功能的使用进行了限制。
 
MC3有哪些改变
 
精确的定义
        清晰地为每个编码规则下一个定义——实际上,这项工作比想象中要难了许多,MC3的开发人员投入大量精力,对有可能产生歧义的定义进行修订。如今,每条定义都包含如下内容:
        说明:阐述本编码规则的具体要求;
        原理:说明本编码规则的必要性;
        例外:列举不适用本编码规则的特殊情况;
        举例:从代码遵从本编码规则和代码不遵从本编码规则两个角度进行举例。
 
必要的术语
        当涉及技术性问题时,使用C语言的术语是很有必要的。这些术语符合ISO C标准,对C语言给出了明确的定义。但是,当对编码规则进行定义的时候,大家有必要引入一些补充性质的“术语”。这一点,在C语言的“类型(type)”系统中显得尤为突出。
        C语言的“类型”系统本身存在着很多不一致现象和异常。由该系统定义的算术表达式的类型看似很直观,但究其根本,这种定义方式却不能体现其本质。为此,MC2引入了基础类型(underlying type)和复杂表达式(complex expression)的概念。然而,现在看来,这两个定义的实际效果差强人意。
        在MISRA C3中,基本类型(essential type)取代了基础类型(underlying type);复合表达式(composite expression)取代了复杂表达式(complex expression)。在定义编码规则时,基本类型以更为直观、更为有效的方式对算术表达式的类型进行描述,包含了完整的整数类型范围:
        ● 基本布尔类型
        ● 基本字符类型
        ● 基本枚举类型
        ● 基本signed类型
        ● 基本unsigned类型
        ● 基本浮点类型
 
强制性规则
        MC1、MC2将编码规则分成两类:必要性规则(Required Rules)以及建议性规则(Advisory Rules)。声称符合MISRA C编码规范的代码,必须遵从所有必要性规则。对于建议性规则,代码开发人员则拥有更多的灵活性。
        “这条编码规则是不是非常重要?”很多时候,这一判断是带有主观色彩的。在进行这一判断的过程中,您需要考虑很多因素,如:
        ● 如果大家违反了这条编码规则,App出错的概率高么?
        ● 在开发过程中,违反这条编码规则的机会大么?
        ● 如果大家已经确定代码是安全的,这条编码规则是否还在不停的报错?
        但是,有一些编码规则,无须任何主观判断,他们简单明了、毫无争议。MC3为他们创建了一个新的分组:强制性规则(Mandatory Rules)。在任何情况下,开发者都不可以违反强制性规则。
 
可实行性
        汽车工业App可靠性协会认为,静态代码检测工具在编码规则的实行过程中起着关键的作用。事实上,人们很早就认识到了编码规则自动实行的重要性:
        ● 消除不确定性;
        ●节省时间;
        ●在代码开发阶段提供实时信息反馈;
        ●减少手动代码检查的工作量。
        实际上,静态代码检测工具绝非一个简单的编码规则实行者,还能识别出编码规则以外的编码错误。
        MC2中有9条编码规则,如果仅依靠源代码分析,是无法对这些编码规则进行合规性判定的,比如:
        ●文档
        ●过程要求
        ●需求的松散定义
        ●主观的评论意见
        ●功能需求的理解
        对于“不要使用逗号运算符”这样的编码规则,简单地对源代码进行分析即可进行合规性判定。但是对于下面的这些规则,仅通过源代码分析,是无法进行合规性判定的:
        ●规则2.4:代码段不应被注释掉;
        ●规则3.2:字符集和相应的编码应该文档化;
        ●规则18.3:内存区域不能为不相关的目的而复用。
 
        MC3指出了“规则”与“指令”之间的区别:
        指令:仅仅依靠源代码分析,无法对“指令”进行合规性判定,往往需要开发人员提供更多的信息,如设计文档和要求说明。静态代码检测工具可以判定代码符合“指令”,但对于代码不符合“指令”的情况,静态代码检测工具给出的判定结果可能千差万别。
        规则:仅仅依靠源代码分析,就可以对“规则”进行合规性判定,不需要开发人员提供更多的信息。所有的静态代码检测工具都应具对“规则”进行合规性判定的能力。
 
实行范围
        编码规则实行的难易程度有着很大的差别。简单的规则(如“不得使用八进制常量”)可以通过简单的语句语法分析进行判定。然而,很多编码规则的判定,需要一条控制语句、一个完整的功能、一个完整的翻译单元、甚至一个项目的整个代码库的支撑才能进行判定。
        在MC3中,每条编码规则都被划分为“系统规则”或“单一翻译单元规则”,用来反映编码规则的实行范围。这两者之间的区别如下:
        ●单一翻译单元无法进行系统规则的合规性判定。
        ●进行系统规则的合规性判定,往往意味着更高的要求及更多的时间。
 
可判定性
        编码规则的另一个重要属性是可判定性。众所周知,编码规则的实行者——静态代码检测工具的能力差别很大。通过上文得知,对于一些简单的编码规则,只需进行简单的语法分析即可实现判定;而对于某些复杂的规则,则需要深入地分析代码的结构和语义。
        对于一些编码规则,其本质是“不可判定的”——不论静态代码检测工具进行多么深入的分析,都无法判定代码的合规性;相反,当某个编码规则被违反,任何工具都可判定且不会误报,那么该规则被认为是“可判定的”。换句话说,任何工具对于“可判定的”编码规则,只会给出两个可能的答案:
        ●Yes – 此处违反该规则;
        ●No –此处没有违反该规则;
        MC3中,所有的规则都被划分为“可判定的”和“不可判定的”两类。共计143条编码规则,其中28条为“不可判定的”。当一个编码规则为“不可判定的”,那么对于这条规则,永远不能保证其合规性,工具可能会给出第三个答案:
        ●无法保证合规性检查结果的准确性。
        然而,大家发现,即使编码规则是可判定的,各种静态代码检测工具对编码规则的判定能力是参差不齐的。
 
差异
        MC3对于那些遵循MC2开发的代码有何影响?MC3旨在解决与C99相关的新问题,其引入的新规则对于遵循MC2开发的代码的影响极为有限。
        实际上,如果一个编码规则存在如下的问题,那么很难称其为好的编码规则。
        ●不能准确判定已知的App故障
        ●允许代码存在规则中明令禁止的危险行为
        ●对于未存在违反行为的代码有着诸多的限制
        MC3对编码规则进行改进,重新编写了一部分规则,将少部分规则完全删除,解除了对编码的限制。
 
结论
        MC3的文档看起来比MC2要大得多,但实际上,编码规则总数并没有增加多少:MC2包含了142条规则,而MC3包含了143条规则和16条指令。MC3在引入新规则的同时,修改了一些规则,也废除了一些规则。MC3的文档之所以大了许多,在于MC3的每条编码规则的体积都“变大”了:
        ●更为精确的规则的描述——包括详细说明、基本原理、例外情况和示例;
        ●增加了规则和指令的区别;
        ●增加了系统规则和单一翻译单元规则之间的区别;
        ●增加了可判定性的内容。
        另外,对于哪些遵循MC2开发的代码,MC3对其造成的影响是极为有限的。
        MISRA C致力于建立一个C语言安全子集,并通过静态代码检测工具自动实行,这使得MISRA编码规范拥有了大量的拥护者。支撑MISRA C编码规则,已经成为众多静态代码检测工具及编译器的基本功能要求。
关于恒润
企业概况
企业理念
企业资质
资讯中心
恒润在全球
诚聘英才
校园招聘
实习生招聘
社会招聘
走进恒润
常见问题
市场活动
在线研讨会
线下活动
微信课堂
用户社区
资料下载
恒润月刊
用户留言
个人中心
相关链接
达索企业
IBM-中国
联系大家
电话:010-64840808
邮箱:market_dept@hirain.com
版权所有 ? yzc88网页版登录 京ICP备18000642号-1 京公网安备11010802017344号 网站地图 | 招聘信息 | 法律声明 | 隐私保护
XML 地图 | Sitemap 地图