The order of evaluation of subexpressions and the order in which side effects take place are frequently defined as unspecified behavior by the C standard. Counterintuitively, unspecified behavior is where the standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance. Consequently, unspecified behavior can be a portability issue because different implementations can make different choices. If dynamic scheduling is used, however, there may not be a fixed-code execution sequence over the life of a process. Operations that can be executed in different sequences may in fact be executed in a different order.
...
Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
Compass/ROSE |
|
| Could detect violations of this recommendation by searching for the following pattern:
| ||||||
| EVALUATION_ORDER | Can detect the specific instance where a statement contains multiple side effects on the same value with an undefined evaluation order because the statement may behave differently with different compiler flags or different compilers or platforms. | |||||||
| 35 D | Fully implemented. | |||||||
| PRQA QA·C |
| Partially implemented |
A programmer could also violate the recommendation using dynamic memory passed to both functions, but that would be extremely difficult to detect using static analysis.
...
ISO/IEC 9899:2011 Section 6.5, "Expressions," Section 6.5.16, "Assignment operators," Section 6.5.2.2, "Function calls," and Section 6.7.9, "Initialization"
ISO/IEC PDTR 24772 "JCW Operator precedence/order of evaluation" and "SAM Side-effects and order of evaluation"
MISRA Rule 12.2
Bibliography
...