Page History

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

According to C99The C standard, Section 6.5 [ISO/IEC 9899:19992011]

...

, states:

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.

(See also undefined behavior 32 35  of Annex J.)

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 C of the C standard [ISO/IEC 9899-1999:2011]:

• Between the evaluations of the function designator and actual arguments in a function call and the actual call.
• Between the evaluations of the first and second operands
• 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: ||
  • comma: ,
• Between the evaluations of the first operand of the conditional ?: ?comma operator: , operator and whichever of the second and third operands is evaluated.
• The end of a full declarator.
• The end Between the evaluation of a full expression and the next full expression to be evaluated. The following are full expressions:
  • an initializer that is not part of a compound literal
  • 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 (optional) expressions of a for statement
  • the (optional) 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 also between any call to a comparison function and any movement of the objects passed as arguments to that call.

...

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

have well-defined behavior, while  and 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;   

...

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 only one way.

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

Or alternatively:

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

Noncompliant Code Example

...

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.

...

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

...

Related Vulnerabilities

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

...

The CERT Oracle Secure Coding Standard for Java: EXP05-J. Do not write more than once to the same variable within an expression

ISO/IEC 9899:19992011] Section 5.1.2.3, "Program execution," Section 6.5, "Expressions," and Annex C, "Sequence points"

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

...