Page History

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 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 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.

According to the C Standard, section subclause 6.5 [ISO/IEC 9899:2011],

Except as specified later, side effects and value computations of subexpressions are unsequenced.

Following are specific examples of situations in which the order of evaluation of subexpressions or the order in which side effects take place is unspecified:

• The order in which the arguments to a function are evaluated (C Standard, section subclause 6.5.2.2, "Function Calls")
• The order of evaluation of the operands in an assignment statement (C Standard, section subclause 6.5.16, "Assignment Operators")
• 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 (C Standard, section subclause 6.7.9, "Initialization")

This recommendation is related to EXP30-C. Do not depend on the order of evaluation between sequence pointsfor side effects, but it focuses on behavior that is nonportable or potentially confusing.

...

Consequently, the result of the following this noncompliant code example depends on unspecified behavior:

#include <stdio.h>

int g;

int f(int i) {
  g = i;
  return i;
}

int main(void) {
  int x = f(1) + f(2);
  printf("g = %d\n", g);
  /* ... */
  return 0;
}

...

This compliant solution is independent of the order of evaluation of the operands and can be interpreted in only one way.:

#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 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 between each other.

Risk Assessment

Automated Detection

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.

Related Guidelines

Bibliography

...

...

Image Modified Image Modified Image Modified