好文档就是一把金锄头!
欢迎来到金锄头文库![会员中心]
电子文档交易市场
安卓APP | ios版本
电子文档交易市场
安卓APP | ios版本

软件编程规范(MISRAC).doc

44页
  • 卖家[上传人]:博****1
  • 文档编号:420857055
  • 上传时间:2023-03-05
  • 文档格式:DOC
  • 文档大小:189.01KB
  • / 44 举报 版权申诉 马上下载
  • 文本预览
  • 下载提示
  • 常见问题
    • 软 件 编 程 规 范目 录一 环境二 语言扩展三 文档四 字符集五 标识符六 类型七 常量八 声明与定义九 初始化十 数值类型转换十一 指针类型转换十二 表达式十三 控制语句表达式十四 控制流十五 switch语句十六 函数十七 指针和数组十八 结构与联合十九 预处理指令二十 标准库二十一 运行时错误一 环境规则1.1(强制): 所有代码都必须遵照ISO 9899:1990 “Programming languages - C”,由ISO/IEC 9899/COR1:1995,ISO/IEC 9899/AMD1:1995,和ISO/IEC9899/COR2:1996 修订规则1.2(强制): 不能有对未定义行为或未指定行为的依赖性这项规则要求任何对未定义行为或未指定行为的依赖,除非在其他规则中做了特殊说明,都应该避免如果其他某项规则中声明了某个特殊行为,那么就只有这项特定规则在其需要时给出背离性规则1.3(强制): 多个编译器和/或语言只能在为语言/编译器/汇编器所适合的目标代码定义了通用接口标准时使用。

      如果一个模块是以非C 语言实现的或是以不同的C 编译器编译的,那么必须要保证该模块能够正确地同其他模块集成C 语言行为的某些特征依赖于编译器,于是这些行为必须能够为使用的编译器所理解例如:栈的使用、参数的传递和数据值的存储方式(长度、排列、别名、覆盖,等等)规则1.4(强制): 编译器/链接器要确保31 个有效字符和大小写敏感能被外部标识符支持ISO 标准要求外部标识符的头6 个字符是截然不同的然而由于大多数编译器/链接器允许至少31 个有效字符(如同内部标识符),因此对这样严格而并不具有帮助性的限制的适应性被认为是不必要的 必须检查编译器/链接器具有这种特性,如果编译器/链接器不能满足这种限制,就使用编译器本身的约束规则1.5(建议): 浮点应用应该适应于已定义的浮点标准浮点运算会带来许多问题,一些问题(而不是全部)可以通过适应已定义的标准来克服其中一个合适的标准是 ANSI/IEEE Std 754 [21]同规则6.3 相一致,浮点类型的定义提供了一个注释所用浮点标准的机会,如:/* IEEE 754 single-precision floating-point */typedef float float32_t;二 语言扩展规则2.1(强制): 汇编语言应该被封装并隔离。

      在需要使用汇编指令的地方,建议以如下方式封装并隔离这些指令:(a) 汇编函数、(b) C函数、(c) 宏出于效率的考虑,有时必须要嵌入一些简单的汇编指令,如开关中断如果不管出于什么原因需要这样做,那么最好使用宏来完成需要注意的是,内嵌的汇编语言的使用是对标准C 的扩展,因此也需要提出对规则1.1的背离define NOP asm (“ NOP”);规则2.2(强制): 源代码应该使用 /*…*/ 类型的注释这排除了如 // 这样C99 类型的注释和C++类型的注释,因为它在C90 中是不允许的许多编译器支持 // 类型的注释以做为对C90 的扩展预处理指令(如#define)中 // 的使用可以改变,/*…*/和//的混合使用也是不一致的这不仅是类型问题,因为不同的编译器(在C99之前)可能会有不同的行为规则2.3(强制): 字符序列 /* 不应出现在注释中C 不支持注释的嵌套,尽管一些编译器支持它以做为语言扩展一段注释以/*开头,直到第一个*/为止,在这当中出现的任何/*都违反了本规则考虑如下代码段:/* some comment, end comment marker accidentally omitted<>Perform_Critical_Safety_Function (X);/* this comment is not compliant */在检查包含函数调用的页中,假设它是可执行代码。

      因为可能会省略掉注释的结束标记,那么对安全关键函数的调用将不会被执行规则2.4(建议): 代码段不应被“注释掉”(comment out)当源代码段不需要被编译时,应该使用条件编译来完成(如带有注释的#if 或#ifdef 结构)为这种目的使用注释的开始和结束标记是危险的,因为C 不支持嵌套的注释,而且已经存在于代码段中的任何注释将影响执行的结果三 文档规则3.1(强制): 所有实现定义(implementation-defined)的行为的使用都应该文档化本规则要求,任何对实现定义的行为的依赖——这些行为在其他规则中没有特别说明的——都应该写成文档,例如对编译器文档的参考如果一个特定的行为在其他规则中被显式说明了,那么只有那项规则在其需要时给出背离完整问题的描述详见ISO 9899:1990 附录 G[2]规则3.2(强制): 字符集和相应的编码应该文档化例如,ISO 10646 [22]定义了字符集映射到数字值的国际标准出于可移植性的考虑,字符常量和字符串只能包含映射到已经文档化的子集中的字符规则3.3(建议): 应该确定、文档化和重视所选编译器中整数除法的实现当两个有符号整型数做除法时,ISO 兼容的编译器的运算可能会为正或为负。

      首先,它可能以负余数向上四舍五入(如,-5/3 = -1,余数为-2),或者可能以正余数向下四舍五入(如,-5/3 = -2,余数为+1)重要的是要确定这两种运算中编译器实现的是哪一种,并以文档方式提供给编程人员,特别是第二种情况(通常这种情况比较少)规则3.4(强制): 所有#pragma 指令的使用应该文档化并给出良好解释这项规则为本文档的使用者提供了产生其应用中使用的任何pragma 的要求每个pragma的含义要写成文档,文档中应当包含完全可理解的对pragma 行为及其在应用中之含义的充分描述应当尽量减少任何pragma 的使用,尽可能地把它们本地化和封装成专门的函数规则3.5(强制): 如果做为其他特性的支撑,实现定义(implementation-defined)的行为和位域(bitfields)集合应当文档化这是在使用了规则6.4 和规则6.5 中描述的非良好定义的位域时遇到的特定问题C 当中的位域是该语言中最缺乏良好定义的部分之一位域的使用可能体现在两个主要方面:􀁺 为了在大的数据类型(同union 一起)中访问独立的数据位或成组数据位该用法是不允许的(见规则 18.4)。

      1048698; 为了访问用于节省存储空间而打包的标志(flags)或其他短型(short-length)数据为了有效利用存储空间而做的短型数据的打包,是本文档所设想的唯一可接受的位域使用假定结构元素只能以其名字来访问,那么程序员就无需设想结构体中位域的存储方式我们建议结构的声明要保持位域的设置,并且在同一个结构中不得包含其他任何数据要注意的是,在定义位域的时候不需要追随规则6.3,因为它们的长度已经定义在结构中了如果编译器带有一个开关以强制位域遵循某个特定的布局,那么它有助于下面的判断例如下面可接受的代码:struct message /* Struct is for bit-fields only */{signed int little: 4; /* Note: use of basic types is required */unsigned int x_set: 1;unsigned int y_set: 1;}message_chunk;如果要使用位域,就得注意实现定义的行为所存在的领域及其潜藏的缺陷(意即不可移植性)特别地,程序员应当注意如下问题:􀁺 位域在存储单元中的分配是实现定义(implementation-defined)的,也就是说,它们在存储单元(通常是一个字节)中是高端在后(high end)还是低端在后(low end)的。

      1048698; 位域是否重叠了存储单元的界限同样是实现定义的行为(例如,如果顺序存储一个6位的域和一个4 位的域,那么4 位的域是全部从新的字节开始,还是其中2 位占据一个字节中的剩余2 位而其他2 位开始于下个字节)规则3.6(强制): 产品代码中使用的所有库都要适应本文档给出的要求,并且要经过适当的验证本规则的对象是产品代码中的任意库,因此这些库可能包含编译器提供的标准库、其他第三方的库或者实验室中自己开发的库这是由IEC 61508 Part 3 建议的四 字符集规则4.1(强制): 只能使用ISO C 标准中定义的escape 序列参见 节中关于有效escape 序列的ISO 标准规则4.2(强制): 不能使用三字母词(trigraphs)三字母词由2 个问号序列后跟1 个确定字符组成(如,??- 代表“~”(非)符号,而??)代表“]”符号)它们可能会对2 个问号标记的其他使用造成意外的混淆,例如字符串“(Date should be in the form ??-??-??)”将不会表现为预期的那样,实际上它被编译器解释为“(Date should be in the form ~~)”五 标识符规则5.1(强制): 标识符(内部的和外部的)的有效字符不能多于31。

      ISO 标准要求在内部标识符之间前31 个字符必须是不同的以保证可移植性即使编译器支持,也不能超出这个限制ISO 标准要求外部标识符之间前6 个字符必须是不同的(忽略大小写)以保证最佳的可移植性然而这条限制相当严格并被认为不是必须的本规则的意图是为了在一定程度上放宽ISO 标准的要求以适应当今的环境,但应当确保31 个字符/大小写的有效性是可以由实现所支持的使用标识符名称要注意的一个相关问题是发生在名称之间只有一个字符或少数字符不同的情况,特别是名称比较长时,当名称间的区别很容易被误读时问题就比较显著,比如1(数字1)和l(L 的小写)、0 和O、2 和Z、5 和S,或者n 和h建议名称间的区别要显而易见在这问题上的特定方针可以放在风格指南中(见 节)规则5.2(强制): 具有内部作用域的标识符不应使用与具有外部作用域的标识符相同的名称,这会隐藏了外部标识符外部作用域和内部作用域的定义如下文件范围内的标识符可以看做是具有最外部(outermost)的作用域;块范围内的标识符看做是具有更内部(more inner)的作用域;连续嵌套的块,其作用域更深入本规则只是不允许一个第二深层(second inner)的定义隐藏其外层的定义,如果第二个定义没有隐藏第一个定义,那么就不算违反本规则。

      在嵌套的范围中,使用相同名称的标识符隐藏其他标识符会使得代码非常混乱例如:int16_t i;{int16_t i; /* This is a different variable *//* This is not compliant */i = 3; /* It could be confusi。

      点击阅读更多内容
      关于金锄头网 - 版权申诉 - 免责声明 - 诚邀英才 - 联系我们
      手机版 | 川公网安备 51140202000112号 | 经营许可证(蜀ICP备13022795号)
      ©2008-2016 by Sichuan Goldhoe Inc. All Rights Reserved.