程序的执行流程是由条件判断、跳转和循环构成的,没有任何一个程序会缺少程序流的控制。那么像if 、for 、while 、switch 等这些程序员无比熟悉的语句也存在隐患吗? 事实上,C 语言是很灵活的,这种灵活性给程序员编写代码带来了很多便利,但同时也带来了很多容易导致混淆的表达。这些表达完全符合C 语言标准,但有时程序员也难以发现自己犯了错误,最终的结果是使程序进入错误的执行流程。即使程序员没有犯错误,但有些容易混淆的表达也会给其他人读懂程序带来困扰,使程序的维护变得困难。除此以外,有少量控制流程的方式还会产生不确定的运行结果,而这些结果也不容易被发觉。
如何使程序的流程控制清晰、准确,不产生混淆的表达呢? MISRA C 给出了很多的相关规定,使程序流的控制变得规范,避免产生各种混淆和不确定性,从而最大程度上减少程序流控制中的失误, 并使程序的维护更加容易。
下面从几个例子出发,讲述这些混淆是如何产生的,最后给出MISRA C 关于程序流控制的相关规则,帮助读者规范编程的习惯。
1 容易混淆的表达方式
先来看这样两段代码:
uint8_t x ,y ;
⋯
if ( x = = y) {
foo ( ) ;
}
uint8_t x ,y ;
⋯
if (x = y) {
foo ( ) ;
}
在C 标准中,条件语句需要的是布尔值,条件语句表达式的布尔值实际上是按照整型处理的,所以这两段代码在语法和逻辑上都没有任何问题。第一段代码判断x 是否等于y ,如果相等,调用foo () 函数;第二段代码首先将y的值赋给x ,然后判断x 是否为0 ,如果不为0 ,调用foo ()函数。这两段代码只相差一个等号,却使判断条件大不相同,程序的执行流程会出现很大差别。
相信读者在写程序的时候都碰到过将“= = ”这个判断语句误写成赋值语句“= ”的情况。那么面对这两个语句时,如何能快速准确地判断这是正确的还是程序员的失误呢? 当程序比较简单的时候,很容易判断,但当程序流程比较复杂的时候,可能花费大量时间还难以给出确定的答案,而这些地方极有可能是有错误的。
这样的混淆,事实上是可以轻松避免的,MISRA C提出了如下强制性的规则。
规则13. 1 :赋值表达式不能用在需要布尔值的地方。
按照MISRA C 的标准,第二段代码应该写成:
uint8_t x ,y ;
⋯
x = y ;
if (x ! = 0) {
foo ( ) ;
}
这样,当看到需要布尔值的地方出现了赋值表达式,
就可以立即判断这是一个错误。在这条规则下,如下的表达也是不允许的:
if ( (x = y) ! = 0 ) ) {
foo ( ) ;
}
与这条规则类似,MISRA C 还提出了如下推荐的规则,来避免整型变量和布尔型的混淆。
规则13. 2 (推荐) :判断一个值是否为0 应该是显式的,除非该操作数是一个布尔值。
这条规则禁止了如下的表达:
uint8_t x ;
⋯
if ( x )
{ ⋯}
再来看一个例子:
uint8_t x ;
uint8_t a ,b ;
⋯
switch ( x ) {
case 1 :
a = b ;
case 2 :
a + = 2 ;
break ;
case 3 :
⋯
}
同样,这段代码在语法和逻辑上也没有任何问题,编译器也不会给出任何错误或者警告。在程序执行中,当x等于1 的时候,将b 的值赋给a ,然后将a 加2 ,退出;当x等于2 的时候,直接将a 的值加2 ,接着退出。但这儿很可能是一段错误的代码,程序员的本意有可能是x 等于1时,将b 的值赋给a ,当x 等于2 时,直接将a 的值加2 。
为了避免这样的混淆,MISRA C 提出了如下强制性的规则。
规则15. 2 :所有非空的switch 子句都应该以break 语句结束。按照这条规则,上面的程序应该写成:
switch ( x ) {
case 1 :
a = b ;
break ;
case 2 :
a + = 2 ;
break ;
case 3 :
⋯
}
或者:
switch ( x ) {
case 1 :
a = b ;
a + = 2 ;
break ;
case 2 :
a + = 2 ;
break ;
case 3 :
⋯
}
MISRA C 中还有一些防止程序流控制中出现混淆的规则。
规则13. 5 :for 语句中的3 个表达式只能和循环控制相关。第一个表达式只能为循环变量赋初值,第二个表达式只能进行循环条件的判断,第三个表达式只能进行循环
变量增(减) 值。规则13. 6 :for 循环中,循环变量只能在for 语句的第三个表达式中修改,不允许在循环体中修改。规则13. 7 :布尔表达式的值必须是可以改变的。例如,如下代码是不允许的:
uint8_t x ;
⋯
if ( x > = 0 )
⋯
错误在于该条件判断的结果始终为真。
规则14. 1 :不能存在无法执行到的代码。规则14. 2 : 非空语句必须要么产生副作用( side-effect) (副作用是指表达式执行后对程序运行环境造成的影响。赋值语句、自
增操作等都是典型的具有副作用的操作。) ;
或者使程序流程改变。例如,下面的代码是不允许的:
⋯
x > = 3 ;
⋯
错误在于x 和3 比较的结果被丢弃了。
规则14. 3 :一行中如果有空语句,那么该行只能有这条空语句,不能有别的语句,并且在这条空语句前不能有注释,注释必须在其后,用空格隔开。例如,如下的代码都是不允许的:
while (port & 0x80 = = 0) {
; foo ( ) ; ①
/ * wait for pin * / ; ②
;/ * wait for pin * / ③
}
其中
的错误是除了空语句还有一条语句;
②的错误是在空语句前有注释;
③的错误是空语句与注释没用空格隔开。
规则14. 8 : switch 、while 、do. . . while 和for 语句的主体必须是复合语句(即用大括号包含) ,即使该主体只包含一条语句。例如,如下代码是符合MISRA C 标准的:
for ( i = 0 ;i < N_EL EMEN TS ; + + i )
{
buffer [ i ] = 0 ;
}
规则14. 9 :if 结构后面必须是一个复合语句(即用大括号包含) ,else 后面必须是一个复合语句(即用大括号包含) 或者另一个if 语句。规则15. 1 : switch 语句的主体必须是复合语句(即用大括号包含) 。规则15. 2 :所有非空的switch 子句都应该用break 语句结束。规则15. 3 : switch 的最后一个子句必须是default 子句,如果default 中没有包含任何语句,那么应该有注释来说明为什么没有进行任何操作。规则15. 4 : switch 表达式不能是一个有效的布尔值。例如,下面的代码是不允许的:
switch ( x = = 0 )
{ ⋯}
规则15. 5 : switch 语句必须至少包含一个case 子句。
2 导致混乱的表达方式
在C 语言中,有一些表达方式可以使程序的代码量减少,但却会使程序的结构化程度降低,流程控制变得混乱,可读性大大降低。看下面一段代码:
if ( a > 0x02 )
{
loop1 : b + = 1 ;
if ( c > 0xA0 ) {
goto loop3 ;
}
loop2 : a = 2 3 b ;
c = a + b ;
if ( c < 0x40) {
goto loop1 ;
}el se {
goto loop2 ;
}
}
⋯
loop3 : ⋯
这段代码读起来很困难。实际编程时,程序员实现这段功能的代码自然不会这样写,但是当程序流程复杂的时候,各种看起来能使编程工作变得轻松的表达,例如goto 、continue 等语句,却会使程序流程变得混乱,可读性降低,而隐藏其中的问题,很可能就无法发现了。
针对这种情况, MISRA C 给出了下面几条强制规则。
规则14. 4 :不允许使用goto 语句。规则14. 5 :不允许使用continue 语句。规则14. 6 :循环体中最多只能出现一个break 语句用于结束循环。规则14. 7 :函数只能有一个出口,这个出口必须在函数末尾。规则14. 10 : if . . . else if 结构必须由一个else 子句结束。当if 语句后面有一个或者多个else if 语句时,最后的一个else if 必须有一个与之对应的else 语句。如果只有一个if 语句时,else 不是必须的。
3 不确定的执行结果
除了导致混淆和混乱的表达外,还有一些对浮点数的操作会导致不确定的结果。来看如下一段代码:
float32_t x ,y ;
⋯ / 3 一些运算3 /
if ( x = = y )
{ ⋯}
if 的条件无法肯定什么情况为真。这是因为浮点数在计算机中无法用二进制精确表示,其运算总会存在舍入和切断误差,很多人看起来相等的结果,但计算机给出的两个浮点数并不相等,所以上面代码中if 的主体语句什么情况执行是不确定的。MISRA C 给出了两条相关的规定来解决这一问题。
规则13. 3 :不允许对浮点数进行相等或者不相等的比较,即使是非直接的比较也是不允许的。
例如,如下非直接的比较也是不允许的:
float32_t x ,y ;
⋯
if ( x < = y )
{ ⋯}
规则13. 4 :for 循环的控制表达式不应包含浮点数类型。
4 小 结
好的代码,要安全可靠、有很好的可读性和可维护性。在C 语言中,一些表达方式,可能会稍微减少程序员编程的工作量,但却会使程序的流程变得难以判断,其中的错误可能就无法发现。
按照MISRA C 的标准来写代码,就可以避免程序流程产生混淆和混乱,排除其中的不确定因素,使程序真正按照程序员设想的工作,并使代码更清晰易懂,真正实现安全可靠,并具有良好的可读性和可维护性。
参考文献
1 MISRA C:2004 ,Guidelines for the use of the C language in critical systems. The Motor Indust ry Software Reliability As2sociation ,2004
2 Harbison III. Samuel P , Steele J r. Guy L. C 语言参考手册,
邱仲潘,等译,第5 版. 北京:机械工业出版社,2003
3 Les Hatton. The MISRA C Compliance Suite The next step , Oakwood Computing. http :/ / www. misra c2. com/
4 ISO/ IEC 9899 :1999. International Organization of Standardi2zation , 1999
