Evaluation of an expression may produce side effects. At specific points during execution, known as sequence points, all side effects of previous evaluations have completed, and no side effects of subsequent evaluations have yet taken place. Do not depend on order of evaluation for side - effects unless there is an intervening sequence point.
...
Note that not all instances of a comma in C code denote a usage of the comma operator. For example, the comma between arguments in a function call is not a sequence point. However, according to the C Standard, subclause 6.5.2.2, paragraph 10 [ISO/IEC 9899:2011]:
...
This rule means that the order of evaluation for function call arguments is unspecified , and can happen in any order.
...
Programs cannot safely rely on the order of evaluation of operands between sequence points. In this noncompliant code example, i is evaluated twice without an intervening sequence point, and so the behavior of the expression is undefined:
| Code Block | ||||
|---|---|---|---|---|
| ||||
void func(int i, int *b) {
int a = i + b[++i];
} |
...
The call to func() in this noncompliant code example has undefined has undefined behavior because there are no sequence points between the argument expressions.
...
The first (left) argument expression reads the value of i (to determine the value to be stored) and then modifies i. The second (right) argument expression reads the value of i between the same pair of sequence points as the first argument, but not to determine the value to be stored in i. This additional attempt to read the value of i has undefined behavior.
Compliant Solution
This compliant solution is appropriate when the programmer intends for both arguments to func() to be equivalent:
| Code Block | ||||
|---|---|---|---|---|
| ||||
extern void func(int i, int j);
void f(int i) {
i++;
func(i, i);
} |
This compliant solution is appropriate when the programmer intends for the second argument to be 1 greater than the first:
...
The order of evaluation for function arguments is unspecified. This noncompliant code example exhibits unspecified behavior, but not undefined behavior:
...
It is unspecified what order a() and b() are called in; the only guarantee is that both a() and b() will be called before c() is called. If a() or b() rely on shared state when calculating their return value, as they do in this example, the resulting arguments passed to c() may differ between compilers or architectures.
...
In this compliant solution, the order of evaluation for a() and b() is fixed, and so no unspecified behavior occurs.
...
Attempting to modify an object multiple times between sequence points may cause that object to take on an unexpected value, which can lead to unexpected program behavior.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
EXP30-C | Medium | Probable | Medium | P8 | L2 |
...
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
...