19-12-2014, 04:25 PM
I think the concern is that any side-effect on the RHS of a logical operator may produce an unexpected result because of the uncertainty as to whether that side-effect will occur or not.
For example, if i has the value 0, and the following is executed:
does i have value 0 or 1? It depends on the values of x and y. Now maybe the programmer who wrote this was perfectly aware of the way in which the operands of logical operands are evaluated. But maybe they weren't and might be surprised to discover that i only increments if x and y have the same value.
In the same way, a programmer may or may not be surprised to find that a volatile access may or may not occur on the RHS of a logical operator. An added problem for volatile accesses is that the nature of the side effect is going to depend on the target processor, the compiler, the design of the program (e.g. using volatile to qualify things that might be accessed from different interrupt levels) and so on. Since a volatile access could, in theory, cause any other volatile object to change its value and/or could cause an output to change state, the best the MISRA rules really can do is to draw attention to the potential issue and suggest, as in the case of this rule, a way of avoiding it.
For example, if i has the value 0, and the following is executed:
Code:
if ((x == y) && (i++ == 10))does i have value 0 or 1? It depends on the values of x and y. Now maybe the programmer who wrote this was perfectly aware of the way in which the operands of logical operands are evaluated. But maybe they weren't and might be surprised to discover that i only increments if x and y have the same value.
In the same way, a programmer may or may not be surprised to find that a volatile access may or may not occur on the RHS of a logical operator. An added problem for volatile accesses is that the nature of the side effect is going to depend on the target processor, the compiler, the design of the program (e.g. using volatile to qualify things that might be accessed from different interrupt levels) and so on. Since a volatile access could, in theory, cause any other volatile object to change its value and/or could cause an output to change state, the best the MISRA rules really can do is to draw attention to the potential issue and suggest, as in the case of this rule, a way of avoiding it.
<t></t>