Evaluation of an expression may produce side effects. At specific points during execution called sequence points, all side effects of previous evaluations have completed and no side effects of subsequent evaluations have yet taken place.

According to C99 Section 6.5 \[[ISO/IEC 9899:1999|AA. References#ISO/IEC 9899-1999]\] (see also [undefined behavior 32 | CC. Undefined Behavior#ub_32] of Annex J):

Between the previous and next sequence point an object can only have its stored value modified once by the evaluation of an expression. Additionally, the prior value can be read only to determine the value to be stored.

This requirement must be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined.

The following sequence points are defined in Annex C, Sequence Points, of C99 \[[ISO/IEC 9899-1999|AA. References#ISO/IEC 9899-1999]\]:

• The call to a function, after the arguments have been evaluated.
• The end of the first operand of the following operators:
  • logical AND: &&
  • logical OR: ||
  • conditional: ?
  • comma operator: ,
• The end of a full declarator.
• The end of a full expression:
  • an initializer
  • the expression in an expression statement (that is, at the semicolon)
  • the controlling expression of a selection statement (if or switch)
  • the controlling expression of a while or do statement
  • each of the expressions of a for statement
  • the expression in a return statement.
• Immediately before a C standard library function returns.
• After the actions associated with each formatted input/output function conversion specifier.
• Immediately before and immediately after each call to a comparison function, by a standard searching or sorting function, and between any call to a comparison function and any movement of the objects passed as arguments to that call.

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.

This rule means that statements such as

i = i + 1;
a[i] = i;

have well-defined behavior, while statements like

/* i is modified twice between sequence points */
i = ++i + 1;  

/* i is read other than to determine the value to be stored */
a[i++] = i;   

do not.

Noncompliant Code Example

Programs cannot safely rely on the order of evaluation of operands between sequence points. In this noncompliant code example, the order of evaluation of the operands to the + operator is unspecified.

a = i + b[++i];

If i was equal to 0 before the statement, the statement may result in the following outcome:

a = 0 + b[1];

Or it may result in the following outcome:

a = 1 + b[1];

Compliant Solution

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

++i;
a = i + b[i];

Or alternatively:

a = i + b[i+1];
++i;

Noncompliant Code Example

The order of evaluation for function arguments is unspecified.

func(i++, i);

The call to func() 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 solution is appropriate when the programmer intends for both arguments to func() to be equivalent.

i++;
func(i, i);

This solution is appropriate when the programmer intends for the second argument to be one greater than the first.

j = i++;
func(j, i);

Risk Assessment

Attempting to modify an object multiple times between sequence points may cause that object to take on an unexpected value. This can lead to unexpected program behavior.

Automated Detection

Splint Version 3.1.1 can detect violations of this rule.

GCC Compiler can detect violations of this rule when the -Wsequence-point flag is used.

Compass/ROSE can detect simple violations of this rule. It needs to examine each expression and make sure that no variable is modified twice in the expression. Also no variable is modified once, and read elsewhere, with the single exception that a variable may appear on both the left and right of an assignment operator.

The Coverity Prevent Version 5.0 EVALUATION_ORDER checker can detect the specific instance where Statement contains multiple side-effects on the same value with an undefined evaluation order because with different compiler flags or different compilers or platforms, the statement may behave differently.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Other Languages

This rule appears in the C++ Secure Coding Standard as EXP30-CPP. Do not depend on order of evaluation between sequence points.

This rule appears in the Java Secure Coding Standard as EXP09-J. Do not depend on operator precedence while using expressions containing side-effects.

References

\[[ISO/IEC 9899:1999|AA. References#ISO/IEC 9899-1999]\] Section 5.1.2.3, "Program execution," Section 6.5, "Expressions," and Annex C, "Sequence points"
\[[ISO/IEC PDTR 24772|AA. References#ISO/IEC PDTR 24772]\] "JCW Operator precedence/Order of Evaluation" and "SAM Side-effects and order of evaluation"
\[[MISRA 04|AA. References#MISRA 04]\] Rule 12.1
\[[Summit 05|AA. 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. References#Saks 07]\]

EXP14-C. Beware of integer promotion when performing bitwise operations on chars or shorts      03. Expressions (EXP)      EXP31-C. Avoid side effects in assertions