Page History

Evaluation of an expression may produce side effects. At specific points during execution called , known as sequence points, all side effects of previous evaluations have completed are complete, and no side effects of subsequent evaluations have yet taken place. Do not depend on the order of evaluation for side effects unless there is an intervening sequence point.

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 next sequence point. According to ISO/IEC 14882-2003:

...

• at the completion of evaluation of each full-expression;
• after the evaluation of all function arguments (if any) and before execution of any expressions or statements in the function body;
• after the copying of a returned value and before the execution of any expressions outside the function;
• after the evaluation of the first operand of the following operators: && (logical AND); || (logical OR); ? (conditional); , (comma, but see the note immediately following);
• after the initialization of each base and member in a class.

...

• .

According to ISO/IEC 14882-2003:

...

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

are allowed, while statements like and statements such as the following are not:

/* 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;   

are notNote 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.

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. i is evaluated twice without an intervening sequence point, and so the behavior of the expression is undefined:

a =#include <stdio.h>

void func(int i, +int b[++i];

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

*b) {
  int a = 0i + b[1++i];

Or it may result in the following outcome:

a = 1 + b[1];
  printf("%d, %d", a, i);
}

Compliant Solution

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

#include <stdio.h>

void func(int i, int *b) {
  int a;
  ++i;
  a = i + b[i];

Or alternatively:

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

Non-Compliant Code Example

  printf("%d, %d", a, i);
}

Alternatively: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;

Noncompliant Code Example

The order of evaluation for function arguments is unspecified.

#include <stdio.h>

void func(int i, int *b) {
  int a = i + b[i + 1];
  ++i;
  printf("%d, %d", a, i);
}

Noncompliant Code Example

The call to func() in this noncompliant code example has undefined behavior because there is no sequence point between the argument expressions:

extern void func(int i, int j);
 
void f(int i) {
  

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

extern void func(int i, int j);
 
void f(int i) {
  i++;
  func(i, i);
}

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

extern void func(int i, int j);
 
void f(int i) {
  int j = i++;
  func(j, i);
}

Noncompliant Code Example

The order of evaluation for function arguments is unspecified. This noncompliant code example exhibits unspecified behavior but not undefined behavior:

extern void c(int i, int j);
int glob;
 
int a(void) {
  return glob + 10;
}

int b(void) {
  glob = 42;
  return glob;
}
 
void func(void) {
  c(a(), b());
}

It is unspecified what order a() and b() are called in; the only guarantee is that both a() and b() will be called before c() is called. If a() or b() rely on shared state when calculating their return value, as they do in this example, the resulting arguments passed to c() may differ between compilers or architectures.

Compliant Solution

In this compliant solution, the order of evaluation for a() and b() is fixed, and so no unspecified behavior occurs:

extern void c(int i, int j);
int glob;
 
int a(void) {
  return glob + 10;
}
int b(void) {
  glob = 42;
  return glob;
}
 
void func(void) {
  int a_val, b_val;
 
  a_val = a();
  b_val = b();

  c(a_val, b_val);
}

Risk Assessment

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

Automated Detection

Related Vulnerabilities

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

Other Languages

...

Related Guidelines

...

...

...

...

Bibliography

...

...

Bibliography

...

 .
[Lockheed Martin 05] AV Rule 204.1 The value of an expression shall be the same under any order of evaluation that the standard permits.
[Saks 07]

...