Page History

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 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 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 (C99C11, Section 6.5.2.2, "Function calls").
• The order of evaluation of the operands in an assignment statement (C99C11, Section 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 (C99C11, Section 6.7.89, "Initialization").

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

...

The order of evaluation of the function designator, the actual arguments, and subexpressions within the actual arguments are unspecified, but there is a sequence point before the actual call. For example, in the function call

(*pf[f1()]) (f2(), f3() + f4())

...

Consequently, the result of the following noncompliant code depends upon 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 only 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;
}

...

Note that while 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.

...

A programmer could One could also violate the recommendation using dynamic memory passed to both functions, but that would be extremely difficult to detect using static analysis.

...

CERT C++ Secure Coding Standard: EXP10-CPP. Do not depend on the order of evaluation of subexpressions or the order in which side effects take place

ISO/IEC 9899:19992011 Section 6.5, "Expressions," Section 6.5.16, "Assignment operators," Section 6.5.2.2, "Function calls," and Section 6.7.89, "Initialization"

ISO/IEC PDTR 24772 "JCW Operator precedence/Order order of Evaluationevaluation" and "SAM Side-effects and Order order of Evaluationevaluation"

MISRA Rule 12.2

Bibliography

...