EXP30-C. Do not depend on order of evaluation between sequence points

The order in which operands in an expression are evaluated is unspecified in C. The only guarantee is that they will all be completely evaluated at the sequence points.

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

The following are the sequence points defined by C99:

• 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, but see the note below).
• The end of a full declarator: declarators.
• The end of a full expression: an initializer; the expression in an expression statement; 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 library function returns (7.1.4).
• After the actions associated with each formatted input/output function conversion specifier.
• Immediately before and immediately after each call to a comparison function, and also 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 the comma operator.

According to C99:

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 rule means that statements such as

i = i + 1;

are allowed, while statements like

i = i++;

are not allowed because they modify the same value twice.

Non-Compliant Code Example

In this example, the order of evaluation of the operands to + is unspecified.

a = i + b[++i];

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

a = 0 + b[1];

Or it may legally result in the following outcome:

a = 1 + b[1];

As a result, programs cannot safely rely on the order of evaluation of operands between sequence points.

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;

Non-Compliant Code Example

Both of these statements violate the rule concerning sequence points stated above, so the behavior of these statements is undefined.

i = ++i + 1;  /* an attempt is made to modify the value of i twice between sequence points */
a[i++] = i;   /* an attempt is made to read the value of i other than to determine the value to be stored */

Compliant Solution

These statements are allowed by the standard.

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

Non-Compliant Code Example

The order of evaluation for function arguments is unspecified.

func(i++, i);

The call to func() has undefined behavior because there's no sequence point between the argument expressions. The first (left) argument modifies i. It also reads the value of i, but only to determine the new value to be stored in i. So far, so good. However, 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;
j++;
func(i, j);

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.

Related Vulnerabilities

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

References

[[ISO/IEC 9899-1999]] Section 5.1.2.3, "Program execution"
[[ISO/IEC 9899-1999]] Section 6.5, "Expressions"
[[ISO/IEC 9899-1999]] Annex C, "Sequence points"
[[Summit 05]] Questions 3.1, 3.2, 3.3, 3.3b, 3.7, 3.8, 3.9, 3.10a, 3.10b, 3.11
Dan Saks. Sequence Points Embedded Systems Design. 07/01/02. http://www.embedded.com/columns/programmingpointers/9900661?_requestid=481957