MISRA-C-2004 工业标准的C编程规范 中文版.pdf

《MISRA-C-2004 工业标准的C编程规范 中文版.pdf》由会员分享，可在线阅读，更多相关《MISRA-C-2004 工业标准的C编程规范 中文版.pdf（86页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、MISRA The Motor Industry Software Reliability Association MISRA-C-:2004 Guidelines for the use of the C language in critical systems 中文版中文版 1 1 背景背景 C 的使用和问题的使用和问题.3 1.1 汽车工业中汽车工业中 C 的使用的使用.3 1.2 语言的不安全性和语言的不安全性和 C 语言语言.3 1.3 安全相关系统中安全相关系统中 C 的使用的使用.4 1.4 标准化标准化.5 2 MISRA-C：视野：视野.6 2.1 MISRA-C 的发布说明

2、的发布说明.6 2.2 MISRA-C 的目标的目标.6 3 MISRA-C：范围：范围.7 3.1 基本的语言问题基本的语言问题.7 3.2 未指出的问题未指出的问题.7 3.3 可应用性可应用性.7 3.4 预备知识预备知识.7 3.5 C+问题问题.7 3.6 自动产生代码的问题自动产生代码的问题.8 4 使用使用 MISRA-C.9 4.1 软件工程环境软件工程环境.9 4.2 编程语言和编码环境编程语言和编码环境.9 4.3 采用子集（采用子集（subset）.11 4.4 符合性声明（符合性声明（Claiming compliance）.13 4.5 持续改进持续改进.13 5 规

3、则简介规则简介.14 5.1 规则分类规则分类.14 5.2 规则的组织规则的组织.14 5.3 规则的冗余规则的冗余.14 5.4 规则的形式规则的形式.14 5.5 理解原始参考理解原始参考.15 5.6 规则的范围规则的范围.17 6 规则规则.18 6.1 环境环境.18 6.2 语言扩展语言扩展.19 6.3 文档文档.19 6.4 字符集字符集.21 6.5 标识符标识符.21 2 6.6 类型类型.23 6.7 常量常量.24 6.8 声明与定义声明与定义.25 6.9 初始化初始化.27 6.10 数值类型转换数值类型转换.27 6.11 指针类型转换指针类型转换.36 6.1

4、2 表达式表达式.37 6.13 控制语句表达式控制语句表达式.43 6.14 控制流控制流.45 6.15 switch 语句语句.48 6.16 函数函数.50 6.17 指针和数组指针和数组.51 6.18 结构与联合结构与联合.54 6.19 预处理指令预处理指令.57 6.20 标准库标准库.62 6.21 运行时错误运行时错误.64 7 References.66 Appendix A:Summary of rules.68 Appendix B：MISRA-C:1998 到到 MISRA-C:2004 规则映射规则映射.74 Appendix C:MISRA-C:1998 已废除

5、的规则已废除的规则.81 Appendix D：ISO 标准交互参考标准交互参考.82 Appendix E:术语表术语表.85 3 1 背景背景 C 的使用和问题的使用和问题 1.1 汽车工业中汽车工业中 C 的使用的使用 MISRA-C:1998 1 发布于 1998 年。本文档是它的修订版本，用来解决与第一版本有关系的问题。在汽车工业领域的实时嵌入式应用中，C 编程语言的使用越来越体现出广泛性和重要性。这在相当程度上取决于该语言固有的灵活性、可支持的范围及其潜在的访问广泛硬件环境的可移植性。详细的理由包括：?对于许多使用中的微处理器来说，如果存在其他除了汇编语言之外的可用语言，通常就是

6、C。在许多情况下，其他语言根本就不可用于硬件。?C 对高速、底层、输入/输出操作等提供了很好的支持，而这些特性是许多汽车嵌入式系统的基本特性。?由于应用的逐步增长的复杂性，高级语言的使用较汇编语言更为适合。?相对于其他一些高级语言，C 能够产生较小的和较少 RAM 密集性（RAM-intensive）的代码。?增长的可移植性需求。市场竞争要求在工程项目生命周期的任何阶段，软件可以通过移植到新的和/或低成本的处理器，目的是为了降低硬件成本。?增长的自动产生 C 代码的使用要求。C 代码需要从模型包中自动产生。?增长的对开放系统和主机环境（hosted enviroments）的兴趣。1.2 语言

7、的不安全性和语言的不安全性和 C 语言语言 没有哪种编程语言能够保证最终的可执行代码会准确地按照程序员预想的那样执行。任何语言都会产生大量的问题，下面为其做了广泛的分类，并描述了 C 语言不安全性的例子。1.2.1 程序员产生错误程序员产生错误 程序员产生的错误，简单的可以是变量名字的书写错误，或者更为复杂的错误，如对算法的误解。编程语言可以承受这样的错误。首先，语言的风格和表达能帮助或提示程序员清晰考虑其算法。其次，对于书写错误，语言可以使从一个有效结构向另一个有效（不是预想的）结构的转换变得轻松或困难。第三，当错误发生时，语言可以检测到也可能检测不到。首先，关于语言的风格和表达，使用 C

8、可以编写出良好布局的、结构化的和表达性强的代码。还可以使用它编写出不正当的和特别难以理解的代码。很明显，后者对于安全相关的系统是不可接受的。其次，C 的语法特性足以使得书写错误也能产生完全有效的代码。例如，在“”（逻辑比较）的地方写成“”（赋值）是很常见的，而且最终结果也几乎总是有效的（但它是错误的）；而 if 语句的结尾出现的多余分号能完全改变代码逻辑。第三，C 的基本观点是假设程序员知道他们在做什么，这意味着错误即使出现也不会被语言注意到而通过。在这方面 C 体现出的软弱性正在于它的“书写检查”（type checking）。举例来说，C 不会拒绝程序员在使用整数代表 true/false

9、 值时却在该整数中存储了浮点值。大多数这样的失配可以简单地通过强制使其合适。如果 C 的表现不得其所（a square peg and a round），4 它不会挑剔而会适合它们！1.2.2 程序员不了解语言程序员不了解语言 程序员可能会误解语言构造的作用。对这样的误解，一些语言是更为开放的。C 语言中有相当多的地方能使程序员轻易产生误解。例如运算符优先级的规则。这些规则是良好定义的，但也非常复杂，也很容易对某特定表达式中运算符的优先级做出错误的假设。1.2.3 编译器的行为同程序员预期的不同编译器的行为同程序员预期的不同 如果语言具有未经完善定义的特性，或者模糊特性，那么在程序员认为某个构

10、造应该如此时，编译器的解释却是完全不同的。C 语言中许多地方是未经完善定义的，因此其行为可能会随着编译器的改变而改变。某些情况下，其行为甚至在同一个编译器内也会根据上下文而发生变化。Annex G 中所有的 C 标准列出了 201 个这种问题。这可以提出相当多的问题，特别是在面临编译器间的移植性时。然而，C 标准 2 列出了这些问题，所以它们能为我们所知。1.2.4 编译器包含错误编译器包含错误 语言的编译器（及其链接器等）本身就是软件工具。编译器可能不会始终正确地编译代码。例如，在特定环境下它们可能同语言标准相违背，或者其本身可能就包含“bug”。因为 C 语言中存在许多难以理解的地方，编译

11、器的编写者很容易错误地解释和实现标准。语言的某些地方比其他的更容易这样。而且编译器的编写者有时会有意改变标准。1.2.5 运行时错误运行时错误 有些不同的语言问题产生自正确编译的代码，但某些特殊数据会在代码运行时产生错误。语言能够对可执行代码内部做运行时的检查以检测这样的错误并执行适当的动作。通常，C 的运行时检查能力比较弱。这也是 C 代码短小有效的原因之一，但是在运行中检查错误就要花费一定的代价。C 编译器通常不为某些常见问题提供运行时检查，诸如数学异常（如零除）、溢出、指针地址的有效性，或数组越界错误。1.3 安全相关系统中安全相关系统中 C 的使用的使用 从 1.2 节可以清楚地知道，

12、在安全相关系统中使用 C 语言需要相当小心。针对上面提及的问题种类，已经为安全相关系统中 C 的使用提出了许多需要关注的事情。显然地，不能为安全相关系统使用所有的 C 语言特性。然而，做为语言来说，C 是非常成熟的，在实践中也是经过了良好分析和使用的。所以它的不足也是众所周知和可以理解的。同时可获得大量的商业工具支持，这些工具用来静态检查 C 源代码和提醒程序员语言问题的存在。如果为了实践的原因有必要在安全相关系统中使用 C 语言，那么必须对语言的使用加以限制，避免那些确实可以产生问题的地方，直到它是可以应用的。本文档为人们提供了这样的限制集合（通常称为“语言子集”（language subs

13、et）。Hatton 3 认为，倘若强加了“严格和自动的强制性约束”，那么 C 能够写出“至少同其他通用语言一样的具有高质量和一致性的软件”。注意，相对于 C 语言，汇编语言不再适合于安全相关系统，在某些方面还会更坏。通常不建议在安全相关系统中使用汇编语言，即使使用也要加以非常严格的约束。5 1.4 标准化标准化 本文档使用的标准是由 ISO 9899:1990 2 定义的 C 编程语言，它是由 ISO/IEC 9899/COR1:1995 4、ISO/IEC 9899/AMD1:1995 5和 ISO/IEC 9899/COR2:1996 6修订的。为了简便，本文档中统称为“C90”。基本的

14、 1990 年文档7是 ANSI X3.159-1989 2的 ISO 版本。在内容上，ISO/IEC 标准同 ANSI 标准是一致的。然而要说明的是，两个标准中章节的编号是不同的，本文档的章节编号随同 ISO 标准。还要说明的是，ANSI 标准7包含了一个有用的附录，其中在某些由标准委员会制定的决策后给出了相关的说明解释。ISO 版本中没有这样的附录。工作小组已经开始考虑 ISO/IEC 9899:19998（称为“C99”）。在本文档的发布日期（2004年 10 月），还没出现嵌入了 C99 的商业编译器。6 2 MISRA-C：视野：视野 2.1 MISRA-C 的发布说明的发布说明 M

15、ISRA协会在1994年发布了它的“Development Guidelines for Vehicle Based Software”9，描述了软件开发过程中所有应该使用的方法集。特别地，在使用中因为考虑安全集成度而做出的语言、编译器和语言特性的选择，成为首要考虑的事情。MISRA 指南9中的节 3.2.4.3（b）和表 3 描述了这些。推荐的方法之一是使用已经应用于航空、能源和国防工业中的标准化的语言子集。本文档定义了这样一个合适的 C 语言子集。2.2 MISRA-C 的目标的目标 在发布这个关于 C 编程语言使用的文档时，MISRA 协会并没想促进 C 在汽车工业中的应用，而是因为认识

16、到了 C 的广泛应用。本文档的目标是为了促进该语言的最为安全的使用。MISRA 协会希望本文档能获得工业上的接受，以及对更安全子集的采用能够成为汽车制造业和许多零部件供应商的最佳实践。它也应该为通用 C 和该特殊子集的使用增加培训和增强使用能力，无论是在个人层次还是公司范围。大部分重点放在了静态检查工具上以强制对子集的适应，同时希望这也会成为汽车嵌入式系统开发者的普遍实践。尽管许多学术著作对语言及其正反两面做了大量的描述，但这方面信息在汽车开发中还不是广为人知。本文档的另外一个目标就是使汽车工业中的工程师和经理们越来越多地关心语言的选用问题。可以帮助进行软件开发的工具，尤其是支持 C 语言使用

17、的工具对我们来说是个好处。然而，对设计与实现的鲁棒性的关注是始终存在的，特别是对安全相关软件的开发。人们希望汽车工业中正在使用的实现软件最佳实践（通过 MISRA 指南9和本文档）的方法能鼓励COTS 工具的供应商使用它以保证其产品适合于汽车工业应用。7 3 MISRA-C：范围：范围 3.1 基本的语言问题基本的语言问题 MISRA 指南9（表 3）要求使用“标准化结构化语言的受限子集”。对 C 来说，这意味着只能使用在 ISO 标准中定义的语言，因此排除了以下方面的使用：?K&R C（由 Kernighan 和 Ritchie 编写的“The C Programming language”

18、的第一版）?C+?C 的私有扩展 3.2 未指出的问题未指出的问题 风格和代码度量问题在一定程度上是很个人化的。对任何一群人来说都很难赞成什么是适当的，而要 MISRA 给出确定性的建议也是不合适的。重要的不是使用者采取了哪种确切的风格或者特定的度量，而是使用者要定义风格指南和合适的度量与限制（见节 4.2.2 和 4.2.4）。MISRA 协会的角色不是建议特定的供应商或工具强制执行所采取的约束。使用本文档的用户在选择工具上是自由的，鼓励供应商提供遵循规则的工具。本文档用户的负担是要声明其工具充分地遵循了规则。3.3 可应用性可应用性 本文档被设计为应用在汽车嵌入式系统的产品代码上。根据 I

19、SO 98992（节 5.1.2）中定义的执行环境，本文档的目标定在“自立（free-standing）的环境”，尽管它也描述了库的问题，因为嵌入式编译器中经常也会用到一些标准库。如果合适，本文档的大部分要求也可以应用在其他嵌入式领域。对主机系统（hosted system）的应用，本文档的要求不是必需的。在进行编译器和静态工具的比较检测（benchmark）时也不需完全应用本文档规则，有时在比较工具时有必要打破这些规则，以测量工具的响应。3.4 预备知识预备知识 本文档不是要做为所涉主题的介绍和培训。而是认为读者熟悉 ISO C 编程语言标准和相关工具，并读过了主要的引用文档。同样假设读者已

20、经接受了适当的培训并胜任 C 程序员工作。3.5 C+问题问题 C+不同于 C 语言，本文档的范围不包含它，也不试图讲解 C+对于编写安全相关系统的适合性与否。然而对于 C+编译器和代码的使用方面应该给出以下说明。C+不仅仅是 C 的超集（即增加多余的 C 特性）。在 C 和 C+中有少数特殊构造具有不同的解释。而且有效的 C 代码可以包含一些在 C+中是保留字的标识符。基于这些原因，由 C8 写成的符合 ISO 标准的代码在 C+编译器中可能不会编译成其在 C 编译器中的结果。因此本文档不赞成使用 C+编译器编译 C 代码。如果为了实用性原因必须使用 C+编译器编译 C 代码，那么首先必须完

21、全理解两种语言的不同之处。然而鼓励使用附加的编译器，如静态检查工具。基于此目的，在不关心可执行代码的地方，可以使用 C+编译器，而且这也确实能提供好处，因为它具有比 C 更强的类型检测能力。如果一个做为“C+”销售的编译器严格地符合了 ISO C 的操作模式，那么它就相当于一个 C 编译器，并可以以 C 编译器的形式使用（只对于 C 代码）。对于其他任何包含了适应 ISO C 编译器的功能部分的工具而言，这也是成立的。C+注释不应用在 C 代码中。尽管 C 编译器支持这种形式的注释（由/表示的），它们也不是 ISO 标准 C 的一部分（见规则 2.2）。3.6 自动产生代码的问题自动产生代码的

22、问题 如果要使用代码自动产生工具，那么有必要选择一个合适的工具并采取有效性验证的手段。建议遵循本文档的要求，它可以提供评估工具的准则，除此之外在这方面没有更多的指南，读者可以参考 HSE 的 COTS 建议10。为了进行有效性验证，对待自动产生代码的方式必须与对待手工产生代码的方式相同（见MISRA 指南9 3.1.3，Planning for V&V）。9 4 使用使用 MISRA-C 4.1 软件工程环境软件工程环境 使用编程语言产生源代码只是软件开发过程中的一个活动。如果只在这样的活动中坚持最佳实践而不考虑其他开发问题，只能带来有限的价值。在安全相关系统的开发中尤其如此。这些问题在 MI

23、SRA 指南9中都提到了，比如：?文档化开发过程?能够满足 ISO 9001/ISO 90003/Tick IT 11，12，13标准的质量体系?项目管理?配置管理?风险分析（Hazard Analysis）?需求?设计?编码?确认（Verificaiton）?有效性验证（Validation）软件开发者有必要证明他们整个的开发过程对其所开发的系统来说是合适的。这样的声明只有当执行完确定系统安全集成度的风险分析活动后才算完成。4.2 编程语言和编码环境编程语言和编码环境 在软件开发过程的编码阶段，语言子集只是许多方面之一，而如果不考虑其他开发问题，只在这一方面中坚持最佳实践，只能带来有限的价值

24、。紧接语言的选择之后的，其他关键问题是：?培训?风格指南（Style guide）?编译器选择和有效性验证?检查工具的验证?度量?测试覆盖率 在这些问题上做出的所有选择及其原因都要记录成文档，并对任何执行的活动保持适当的记录。然后，在需要时这样的文档可以包含进安全性声明中。4.2.1 培训（培训（Training）为了确保 C 代码编写者具有合适的熟练程度和能力，应该提供正规训练：?嵌入式应用中 C 编程语言的使用 10?高度集成的和安全相关的系统中 C 编程语言的使用?用于强制遵循子集的静态检查工具的使用 4.2.2 风格指南（风格指南（Style guide）除了采用语言子集外，一个组织应

25、该有其自己的实验室内的编程风格。这包含那些不直接影响代码正确性但定义了代码呈现形式的“实验室风格”（house style）的问题。这些问题是主观的。风格指南涉及的典型问题包括：?代码布局和缩进的使用?大括号“”和结构块的布局?语句的复杂性?命名规范?注释语句的使用?公司名称、版权提示和其他标准文件头信息的包含 正如风格指南的某些内容是建议性的，某些内容也是强制性的。然而，对风格的强制不在本文档所讨论的范围之内。关于风格的更多信息参见14。4.2.3 工具选择和有效性验证工具选择和有效性验证 在选择编译器（可以理解为包括链接器）时，尽可能地要使用适应 ISO C 的编译器。如果语言的使用依赖于

26、“实现定义”（implementation-defined）的特性（如 ISO 标准2的 Annex G.3中所确认的），那么开发者必须检测编译器以确认其实现与编译器编写者所声明的一致。Annex G 的更多解释见 5.5.2 节。在选择静态检查工具时，很明显地需要该工具尽可能多地强制遵循本文档的规则。为了这个目标，重要的是工具能在整个程序范围内进行检查，而不是单单一个源文件。另外，如果一个检查工具能执行超出本文档要求之外的检查，建议进行额外的检查。编译器和静态检查工具通常被视作“可信的”（trusted）过程。这意味着对工具的输出具有相当程度的信任，因此程序员必须要确保这样的信任不是一种错信

27、。理想的是，这种信任应该由工具的供应商通过运行合适的有效性测试来达到。需要说明的是，虽然能采用有效性验证的方法来为一个嵌入式目标测试编译器，但在本文档发布时还没有这样的形式化验证机制。另外，这些工具应该被开发成能够满足 ISO 9001/ISO 9000311，12，13的质量体系。工具的供应商应该能提供确认和有效性验证活动的记录以及软件的可控开发过程的变更记录。供应商应该具有下面的机制：?记录由用户报告的缺陷?对现有客户通告已知的缺陷?在未来的发布中改正缺陷 现有客户群的规模以及对前 6 到 12 个月报告的缺陷的观察能够说明工具的稳定性。通常不大可能从供应商那里得到这等层次的保证，在这些情

28、况下开发者的职责是确保工具具有足够的质量。开发者可以采用的增强工具信心的可能手段是：?执行某种形式的文档化验证测试?评估工具供应商的软件开发过程 11?检阅工具迄今为止的性能 可以通过创建代码例子在工具上运行来执行有效性验证。对编译器来说，它可以由前面应用中已知的良好代码组成。对静态检查工具，应该写一套代码文件，每个文件打破子集中的一条规则，并且所有文件在一起要覆盖尽可能多的规则。然后，静态检查工具为每个测试文件发现不适应的代码。尽管这样的测试是受限的，它们也将确立基本层次上的工具行为。需要说明的是，在做编译器的有效性验证时，要使用与编译产品代码时相同的编译器选项、链接器选项和源文件库版本。4

29、.2.4 源代码复杂度源代码复杂度 强烈建议使用源代码的复杂性度量。这可以防止编写出难以控制和难以测试的代码。同样高度建议使用工具进行数据的搜集工作。许多可以用于强制遵循子集的工具同样具有产生度量数据的能力。详细的源代码度量参见“Software Metrics:A Rigorous and Practical Approach”（Fenton 和Pfleeger）15，以及 MISRA 关于软件度量的报告16。4.2.5 测试覆盖率测试覆盖率 在软件设计和编写之前，应该定义好它期望达到的语句覆盖率。代码的设计和编写应该能使其在测试中达到很高的语句覆盖率。在机械、电气和电子领域，这个概念有个术

30、语叫“Design For Test”（DFT）。在编写代码的过程中就应该考虑这个问题，因为达到高语句覆盖的能力是源代码的新兴属性。使用子集，它减少了定义实现的属性的数量和增加了模块接口兼容性，能产生可以进行较大规模集成和测试的软件。折中考虑以下的度量可以促进高语句覆盖率的实现：?代码规模?圈复杂度?静态路径数目 使用计划好的方法，在软件设计、语言使用和 DFT 上的花费可以由测试阶段中要达到高语句覆盖率所需时间的缩减来补偿。见16，17。4.3 采用子集（采用子集（subset）为了开发符合子集要求的代码，需要遵循以下步骤：?产生一个符合性矩阵（compliance matrix），声明是如

31、何强制每个规则的?产生一个背离（deviation）过程?在质量管理系统中统一工作实践的形式 4.3.1 符合性矩阵（符合性矩阵（Compliance matrix）为了确保所编写的代码符合子集，有必要进行适当的测量，检查它没有打破规则。要做到这一点最有效的手段是，使用一个或多个静态检查工具。如果工具不能检查某条规则，那么就必须进行人工检查。为了确保所有的规则都覆盖到了，就需要产生一个符合性矩阵，矩阵中列出每条规则并说明它是如何被检查的。例如表 1。见附录 A 中的规则列表，它可以帮助产生完整的符合性矩阵。12 Rule No.Comiler1 Compiler2Checking Tool 1

32、 Checking Tool 2 Manual Review 1.1 Warning 347 1.2 Error 25 1.3 Message 38 1.4 Warning 97 1.5 Proc x.y Table 1:Example compliance matrix 如果开发者具有其他的本地约束，也可以加入到符合性矩阵中。在忽略特定约束的地方，要给出完整的说明。这些说明必须是能被 C 语言专家和管理者一同承认的。4.3.2 背离过程（背离过程（Deviation procedure）要知道在某些情况下需要背离本文档给出的规则。例如，与微处理器硬件接口的源代码会不可避免地需要使用适当的语言

33、扩展。为了具有权威性，有必要使用一个正规的过程来认可这些背离，而不是依靠一个个体的程序员随意背离规则的判断力。背离的使用必须在必要性和安全性上被声明为是正确的。由于本文档不打算给出每条规则的重要等级，因此如果说某些条款是比其他条款更为关键也是可以接受的。这将反映在背离的过程中，如果对于更为严重的背离，需要更强的技术能力以评估即将招致的风险，需要更高的管理以接受这种增加的风险。如果存在正规化的质量管理系统，那么背离过程应该是该系统的一部分。背离的发生可以是针对某一特殊实例，即在单一文件中一次性出现的事物，或者是针对某一类环境，即一特定环境中特定结构的系统级使用，如使用特定的语言扩展实现处理串口通

34、讯的文件 I/O 操作。严格遵循所有规则是不大可能的，而且在实际中，与个体情形有关的背离是可以容许的。背离的种类有两种：?项目背离（Project Deviation）：项目背离定义为可允许的对规则要求的放宽，以应用在特殊环境中。实际上，项目背离在项目开始时总是可以的。?特定背离（Specific Deviation）：特定背离定义为在某个文件中对某规则的背离，典型地由对环境的响应给出。特定背离发生在开发过程中。项目背离需要正规地检查回顾，这样的检查应该是形式化背离过程的一部分。一些需要打破规则的环境关心的是输入/输出的操作。建议软件的设计要使得对输入/输出的关注同软件的其他部分隔离开来。在代

35、码的输入/输出部分中要尽可能地限制项目背离。服从于项目背离的代码应该标记出来。本文档的目标是要仔细考虑这些问题并采取可靠的手段以避免这些问题。不应该使用背离过程去破坏这样的思想。在遵循本文档的规则时，开发者同时也利用了 MISRA 在理解这些问题时所做出的努力。如果要背离规则，那么开发者就必须要理解问题本身。所有的背离，包括标准的和特定的，都应该记录成文档。例如，如果预先知道很难遵循某一规则，软件开发者应该提交一份项目背离请求（Project Deviation Request）并在开始编程之前征得客户方的同意。项目背离请求应该包含如下内容：?背离的细节，即被背离的规则?需要产生背离的环境?由

36、背离产生的潜在后果?对背离的正确性声明 13?声明如何保障安全性 如果在开发过程期间或结尾出现了对背离的需求，软件开发者应该提交一份特定背离请求（Specfic Deviation Request）。特定背离请求应该包含如下内容：?背离的细节，即被背离的规则?由背离产生的潜在后果?对背离的正确性声明?声明如何保障安全性 这些过程的实现细节留给用户决定。4.3.3 质量体系中的形式化质量体系中的形式化 子集、静态检查工具和背离过程的使用应该由形式化的文档在质量管理体系中做出描述。然后它们要经过与质量体系相关的内部和外部审查，这将促进它们的一致性使用。4.3.4 引入子集引入子集 如果一个组织已经

37、具有 C 代码编程环境，那么建议引入本文档规则（见 Hatton3的第五章）。实现本文档的所有内容可能需要 1 到 2 年的时间。如果某产品包含了在使用子集前编写的代码，重写这些代码以适应子集可能是不现实的。在这种情况下，开发者必须决定管理引入子集的策略（例如：所有新模块要写成符合子集的方式，而对于已存在的模块，如果它们要做出超过非注释语句 30的更改，那么就要重写成符合子集的形式）。4.4 符合性声明（符合性声明（Claiming compliance）只能为产品而不能为组织声明符合性。在为一个产品声明 MISRA-C 文档的符合性时，开发者的意思是在说，存在着体现下列内容的依据：?完成了符

38、合性矩阵，它显示出如何强制符合性的?产品中所有 C 代码与本文档的规则是一致的，或者遵循了对文档规则的背离?维持了没有遵循的所有规则实例列表，对每个实例来说，?4.2 节中提到的问题已经解决了 4.5 持续改进持续改进 对本文档规则的遵循只是持续改进过程的第一步。用户必须要知道其他主题内容（见参考），并且要主动使用度量寻求开发过程的改进。14 5 规则简介规则简介 这一节描述文档第 6 节中规则的表达方式。是文档主要内容的简单介绍。5.1 规则分类规则分类 第 6 节中的每条规则都被分类成“强制”（required）或“建议”（advisory），在后面描述。在这个基本分类之外，文档不打算给出

39、每条规则的重要等级。所有强制的规则具有同等重要性，所有建议的规则也如此。文档中对某一项的忽略也不表明它的重要性较低。“强制”和“建议”的含义如下：5.1.1 强制规则强制规则 这是对程序员的强制要求。文档中共有 121 条“强制”规则。声明遵循本文档的 C 代码应该适合每条强制规则，如果不是，就需要具有形式化的背离，见 4.3.2 节。5.1.2 建议规则建议规则 这些要求程序员在通常情况下都要遵守。然而它们不象强制规则那样带有强迫性质。文档中共有 20 条“建议”规则。要说明的是，“建议”不意味着可以忽略这些规则，而是应该遵守直至合理的实现。对建议规则来说不需要形式化的背离，但如果背离是适当

40、的，也可以产生。5.2 规则的组织规则的组织 规则被组织在 C 语言的不同主题下。但不可避免地会有一些重叠，一条规则可能会同一些主题相关。这种情况下，规则被安排在最具相关性的主题下。5.3 规则的冗余规则的冗余 本文档中存在少数这样的情况，某规则的给出针对某一语言特性，该语言特性在某处是禁止的而在他处却是建议使用的。这是有意的。用户可能要通过以下两种方式选用该语言特性，或者是产生对某强制规则的背离，或者是选择不遵循某条建议规则。这种情况下，第二条限制语言特性使用的规则成为相关的规则。5.4 规则的形式规则的形式 本文档中的个体规则书写形式如下：各内容如下：?：每条规则带有唯一的序号。序号的前缀

41、是规则的组别，后缀是在规则组中的序号。规则规则 ():15?：或者是“强制”，或者是“建议”，见 5.1 节中的解释?：规则内容?：指示了产生本条款或本组条款的可应用的主要来源。5.5 节描述了这些参考的重要性以及到原始材料的连接。另外，对每项条款或成组相关条款提供了支持文本。该文本描述了规则所涉及的基本问题及如何应用规则的例子。如果在某一规则后没有紧跟这样的解释文本，那么对应文本会在一组规则后找到，这段文本适应于其前所有规则。类似地，一组规则后的原始参考适用于整组规则。支持文本不是做为相关语言特性的指南，我们假设读者已经具有关于语言的工作经验。语言特性的更为详细的信息可以通过咨询相关的语言标

42、准或其他 C 语言参考书来获得。如果原始参考给出了一个或多个 ISO 标准中“Annex G”条款，那么 ISO 标准中提出的原始问题将有助于对规则的理解。在代码段中，下列已经 typedef 定义的类型假设为（为了适应规则 6.3）：char_t plain 8 bit character uint8_t unsigned 8 bit integer uin16_t unsigned 16 bit integer uint32_t unsigned 32 bit integer int8_t signed 8 bit integer int16_t signed 16 bit integer

43、 int32_t signed 32 bit integer float32_t 32 bit floating-point float64_t 64 bit floating-point 非特意定义的变量名称指示其类型。例如：uint8_t u8a;sint32_t s32a;5.5 理解原始参考理解原始参考 当规则来源于一个或多个已发表的原始文件时，这些来源会在一个方括号中标明。这样做有两个目的。首先，读者可以咨询这些特定的资源以充分了解规则之后的基本原理（比如需要对规则有所背离的时候）。其次，考虑到 ISO 标准中“Annex G”提到的问题，这些资源的类型给出了这些问题性质的额外信息（

44、见 5.5.2 节）。下面给出连接这些资源的关键字及相关解释。5.5.1 原始参考关键字原始参考关键字 Reference Source Annex G of ISO 9899 2 Unspecified Unspecified behavivour(G.1)Undefined Undefined behavivour(G.2)Implementation Implementation-defined behaviour(G.3)Locale Locale-specific behaviour(G.4)16 Other MISRA Guidelines The MISRA Guidelines

45、 9 K&R Kernighan and Ritchie 18 Koenig“C Traps and Pitfalls”，Koenig 19 IEC 61508 IEC 61508:1998-2002 20 参考后面出现数字时，它们具有如下含义：?ISO 9899 参考的 Annex G：该条款在 Annex 中相应章节中的序号，序号从该章节的开始处计算。所以，Locale 2代表标准中 G.4 节的第二条款。?在排列参考时给出相应的页数（除非另外声明）。5.5.2 理解理解 Annex G 参考参考 如果规则是基于 ISO C 标准中的 Annex G，理解以下问题的区别将对读者有所帮助，即

46、“unspecified”、“undefined”、“implementation-defined”和“locale-specific”。这里给出简单的解释，详细信息请参考 Hatton3。5.5.2.1 Unspecified 这些是必须成功编译的语言结构，但关于结构的行为，编译器的编写者有某些自由。例如规则 12.2 中描述的“运算次序”。这样的问题有 22 个。在某种方式上完全相信编译器的行为是不明智的。编译器的行为甚至不会在所有可能的结构中都是一致的。5.5.2.2 Undefined 这些是本质的编程错误，但编译器的编写者不一定为此给出错误信息。相应的例子是无效参数传递给函数，或函数

47、的参数与定义时的参数不匹配。从安全性角度这是特别重要的问题，因为它们代表了那些不一定能被编译器捕捉到的错误。5.5.2.3 Implementation-defined 这有些类似于“unspecified”问题，其主要区别在于编译器要提供一致的行为并记录成文档。换句话说，不同的编译器之间功能可能会有不同，使得代码不具有可移植性，但在任一编译器内，行为应当是良好定义的。比如用在一个正整数和一个负整数上的整除运算“/”和求模运算符“%”。存在 76 个这样的问题。从安全性角度，假如编译器完全地记录了它的方法并坚持它的实现，那么它可能不是那样至关重要。尽可能的情况下要避免这些问题。5.5.2.4

48、Locale-specfic 这是与国际标准有所不同的一些小的特性。如在表示十进制的小数点时使用“，”字符替代“.”字符。有 6 个这样的问题。本文档没有涉及这项资源提出的问题。17 5.6 规则的范围规则的范围 原则上，规则要用在应用程序的所有程序文件。虽然多数规则可以用在单独的文件中，规则 1.1、1.2、1.3、1.4、2.1、3.6、5.1、5.3、5.4、5.5、5.6、5.7、8.4、8.8、8.9、8.10、12.2、12.4、14.1、14.2、16.2、16.4、17.2、18.1、18.2、18.3 和 21.1 必须要用在所有文件中。18 6 规则规则 6.1 环境环境

49、规则规则 1.1（强制）：（强制）：所有代码都必须遵照所有代码都必须遵照 ISO 9899:1990“Programming languages-C”，由”，由 ISO/IEC 9899/COR1:1995，ISO/IEC 9899/AMD1:1995，和，和 ISO/IEC 9899/COR2:1996 修订。修订。MISRA Guidelines Table 3；IEC 61508 Part 7:Table C.1 这些方针建立在 ISO 9899:1990 2 之上，它是由 ISO/IEC 9899/COR1:1995 4，ISO/IEC 9899/AMD1:1995 5 以及 ISO/

50、IEC 9899/COR2:1996 6 修订的。并没有适应于 ISO 9899:1999 8 标准版本的声明，本文档中任何提及“Standard C”的地方都是指旧有的 ISO9899:1990 2 标准。必须认识到“背离”（描述见 4.3.2 节）的提出是必要的，这能允许一定的语言扩展，比如对硬件特性的支持。当 ISO 9899:1990 5.2.4 2 中指定的环境限制超出了范围，就需要提出“背离”，除了后面的规则 5.1。规则规则 1.2（强制）：（强制）：不能有对未定义行为或未指定行为的依赖性。不能有对未定义行为或未指定行为的依赖性。这项规则要求任何对未定义行为或未指定行为的依赖，除