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. Consequently, unspecified behavior can be 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.
...
Specific examples of situations where the order of evaluation of subexpressions or the order in which side effects take place is unspecified include:
- the The order in which the arguments to a function are evaluated (C99, Section 6.5.2.2, "Function calls").
- the The order of evaluation of the operands in an assignment statement (C99, Section 6.5.16, "Assignment operators").
- the 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").
...
For example, in the function call:
| Code Block |
|---|
(*pf[f1()]) (f2(), f3() + f4()) |
...
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 in between each other.
...