lol总决赛下注

登录 | 注册 | English

资讯中心

lol总决赛下注  >  资讯中心  >  产品动态

第三代MISRA C编码规范

背景
        汽车工业App可靠性协会(MISRA),是在英国政府 的大力支撑下,由多家汽车工业企业 的代表组成,旨在规范汽车电子中App 的应用,并为嵌入式App 的发展提供引导意见。
        汽车工业App可靠性协会于1998年推出了一代MISRA C编码规范:MISRA C:1998,主要面向对代码可靠性有着强烈需求 的领域。经过多年 的发展,MISRA C已经从汽车行业编码规范发展成为跨行业 的编码规范,成为世界范围内使用广泛 的C语言编码规范。
        2013年3月,汽车工业App可靠性协会将推出第三代MISRA C编码规范:MISRA C:2012,本文将就这一新版本进行深入讨论。
 
引言
        二十世纪九十年代,汽车电子产品 的重要性日益凸显,汽车电子产品中 的App也随之变得举足轻重。人们迫切地需要一个编码规范来保证汽车电子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编码规则,已经成为众多静态代码检测工具及编译器 的基本功能要求。
关于lol总决赛下注
企业概况
企业理念
企业资质
资讯中心
lol总决赛下注在全球
诚聘英才
校园招聘
实习生招聘
社会招聘
走进lol总决赛下注
常见问题
市场活动
在线研讨会
线下活动
微信课堂
用户社区
资料下载
lol总决赛下注月刊
用户留言
个人中心
PMT留言
相关链接
达索企业
IBM-中国
联系大家
电话:010-64840808
邮箱:market_dept@hirain.com
版权所有 ? lol总决赛下注_lol竞猜平台 京ICP备18000642号-1 京公网安备11010802017344号 网站地图 | 招聘信息 | 法律声明 | 隐私保护
XML 地图 | Sitemap 地图