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 intuitively, unspecified behavior is where the standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance. An example of unspecified behavior is the order in which the arguments to a function are evaluated.

Unspecified behavior is generally a portability issue, as 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, may in fact be executed in a different order.

According to C99, Section 6.5, "Expressions":

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.

The order of evaluation of the operands in an assignment statement is also unspecified (C99, 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 (C99, Section 6.7.8, "Initialization").

Non-Compliant Code Example

Programs cannot safely rely on the The order of evaluation of operands between sequence points. In this non-compliant code example, the order of evaluation of the operands to the + operator is unspecified.the function designator, the actual arguments, and subexpressions within the actual arguments is unspecified, but there is a sequence point before the actual call.

For example, in the function call:

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

the functions f1(), f2(), f3(), and f4() may be called in any order. All side effects have to be completed before the function pointed to by pff1() is called.

Consequently, the result of this non-compliant code example depends upon unspecified behavior:

int g;

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

int main(void) {
  int x = f(1) + f(2); /* Line B */ 
  /* ... */
  return 0;
}

This code may result in g being assigned the value 1, or equally likely, being assigned the vlaue value 2.

Compliant Solution

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

int g;

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

int main(void) {
  int x = f(1); 
  x += f(2);
  /* ... */
  return 0;
}

...

\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 5.1.2.36.5, "Program executionExpressions," Section 6.5.16, "ExpressionsAssignment operators," and Annex CSection 6.7.8, "Sequence pointsInitialization"
\[[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.1
\[[Summit 05|AA. C References#Summit 05]\] Questions 3.1, 3.2, 3.3, 3.3b, 3.7, 3.8, 3.9, 3.10a, 3.10b, and 3.11
\[[Saks 07|AA. C References#Saks 07]\]

...

DCL13-A. Function arguments that are pointers to values not changed by the function should be declared const      03. Expressions (EXP)       EXP31-C. Do not modify constant values