The order of evaluation of subexpressions , and the order in which side effects take place , are frequently defined as unspecified behavior by C99. Counter intuitivelythe C Standard. Counterintuitively, unspecified behavior is where in behavior for which 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 , as different 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 orderings different sequences may in fact be executed in a different order.
According to C99the C Standard, Section subclause 6.5 , "Expressions":[ISO/IEC 9899:2011],
Except as specified later (for the function-call
()
,&&
,||
,?:
, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified., side effects and value computations of subexpressions are unsequenced.
Following are specific examples of situations in which the Specific examples of situations where the order of evaluation of subexpressions or the order in which side effects take place is unspecified include:
- The order in which the arguments to a function are evaluated (C99C Standard, Section subclause 6.5.2.2, "Function callsCalls").
- The order of evaluation of the operands in an assignment statement (C99C Standard, Section subclause 6.5.16, "Assignment operatorsOperators").
- The order in which any side effects occur among the initialization list expressions is unspecified. In particular, the evaluation order need not be the same as the order of subobject initialization (C99C Standard, Section subclause 6.7.89, "Initialization").
This recommendation is related to EXP30-C. Do not depend on the order of evaluation between sequence points, but for side effects, but it focuses on behavior that is non-portable nonportable or potentially confusing.
...
Noncompliant Code Example
The order of evaluation of the function designator, the actual arguments, and subexpressions within the actual arguments is are unspecified, but there is a sequence point before the actual call. For example, in the function call
Code Block |
---|
(*pf[f1()]) (f2(), f3() + f4())
|
the functions {{ Wiki Markup f1()
}}, {{f2()
}}, {{f3()
}}, and {{f4()
}} may be called in any order. All side effects have to be completed before the function pointed to by {{pf
\[f1()
\]
}} is called.
Consequently, the result of the following non-compliant code depends upon this noncompliant code example depends on unspecified behavior:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio.h> int g; int f(int i) { g = i; return i; } int main(void) { int x = f(1) + f(2); /* Line B */ printf("g = %d\n", g); /* ... */ return 0; } |
This code may result in g
being assigned the value 1
, or equally likely, being assigned the value 2
.
Compliant Solution
This compliant solution is independent of the order of evaluation of the operands and can only be interpreted in only one way.:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio.h> int g; int f(int i) { g = i; return i; } int main(void) { int x = f(1); x += f(2); printf("g = %d\n", g); /* ... */ return 0; } |
This code always results in g
being assigned the value 2
.
Exceptions
EXP10-C-EX1: The &&
and ||
operators guarantee left-to-right evaluation; there is a sequence point after the evaluation of the first operand.
EXP10-C-EX2: The first operand of a condition expression is evaluated; there is a sequence point after its evaluation. The second operand is evaluated only if the first compares unequal to 0; the third operand is evaluated only if the first compares equal to 0.
EXP10-C-EX3: There is a sequence point before function calls, meaning that the function designator, the actual arguments, and subexpressions within the actual arguments are evaluated before the function is invoked.
EXP10-C-EX4: The left operand of a comma operator is evaluated followed by before the right operand is evaluated. There is a sequence point in between.
Note that while whereas commas serve to delimit multiple arguments in a function call, these commas are not considered " comma operators. " Multiple arguments of a function call may be evaluated in any order, with no sequence points in between each other.
Risk Assessment
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
EXP10- |
C |
Medium |
Probable |
Medium | P8 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| evaluation-order multiple-volatile-accesses | Partially checked | ||||||
Axivion Bauhaus Suite |
| CertC-EXP10 | Fully implemented | ||||||
CodeSonar |
| LANG.STRUCT.SE.IOE | Indeterminate Order of Evaluation | ||||||
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 | |||||||
Helix QAC |
| C0400, C0401, C0402, C0403, C0404, C0405, C3226, C3326 | |||||||
LDRA tool suite |
| 35 D, 72 D, 1 Q, 134 S | Fully implemented | ||||||
Parasoft C/C++test |
| CERT_C-EXP10-a | The value of an expression shall be the same under any order of evaluation that the standard permits | ||||||
PC-lint Plus |
| 564, 931 | Partially supported | ||||||
Polyspace Bug Finder |
| CERT C: Rec. EXP10-C | Checks for situations where expression value depends on order of evaluation or side effects (rec. fully covered) | ||||||
PVS-Studio |
| V521, V681 | |||||||
RuleChecker |
| evaluation-order multiple-volatile-accesses | Partially checked |
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.
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
Wiki Markup |
---|
\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.5, "Expressions," Section 6.5.16, "Assignment operators," Section 6.5.2.2, "Function calls," and Section 6.7.8, "Initialization"
\[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "JCW Operator precedence/Order of Evaluation" and "SAM Side-effects and order of evaluation"
\[[MISRA 04|AA. C References#MISRA 04]\] Rule 12.2 |
Related Guidelines
SEI CERT C++ Coding Standard | EXP50-CPP. Do not depend on the order of evaluation for side effects |
ISO/IEC TR 24772:2013 | Operator Precedence/Order of Evaluation [JCW] Side-effects and Order of Evaluation [SAM] |
MISRA C:2012 | Rule 13.5 (required) |
Bibliography
[ISO/IEC 9899:2011] | Subclause 6.5, "Expressions" |
...
EXP09-A. Use sizeof to determine the size of a type or variable 03. Expressions (EXP) EXP11-A. Do not apply operators expecting one type to data of an incompatible type