Page History

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 during execution, known as sequence points, all side effects of previous evaluations have completedare complete, and no side effects of subsequent evaluations have yet taken place.

The following are the sequence points defined by C99:

Do not depend on the order of evaluation for side effects unless there is an intervening sequence point.

The C Standard, 6.5, paragraph 2 [ISO/IEC 9899:2024], 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.

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

The following sequence points are defined in the C Standard, Annex C [ISO/IEC 9899: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 of the following operators:
  • Logical AND: &&
  • Logical OR: ||
  • Comma: ,
• Between the evaluations of the first operand of the conditional ?: operator and whichever of the second and third operands is evaluated
• 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.
• Between the evaluation The end of a full expression : an initializer; the 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
  ; the
  • The controlling expression of a selection statement (if or switch)
  ; the
  • The controlling expression of a while or do statement
  ; each
  • Each of the (optional) expressions of a for statement
  ; the
  • The (optional) 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:

Furthermore, Section 6.5.17.1, paragraph 3 [ISO/IEC 9899:2024] says (regarding assignment operations):

The side effect of updating the stored value of the left operand is sequenced after the value computations of the left and right operands. 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

ia[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.have defined behavior, and statements such as the following do not:

a/* i is modified twice between sequence points */
i = ++i + b[++i];
 1;  

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

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. However, according to the C Standard, 6.5.3.3, paragraph 8 [ISO/IEC 9899:2024]

Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function.

This rule means that the order of evaluation for function call arguments is unspecified and can happen in any order.

Noncompliant Code Example

Programs cannot safely rely on the order of evaluation of operands between sequence points. In this noncompliant code example, i is evaluated twice without an intervening sequence point, so the behavior of the expression is undefinedIf 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:

#include <stdio.h>

void func(int i, int *b) {
  int 

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

...

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

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

Or alternatively:

#include <stdio.h>

void func(int i, int *b) {
  int a;
  ++i;
  a = i + b[i+1];
++i  printf("%d, %d", a, 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.

}

Alternatively:

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.

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

Related Guidelines

Key here (explains table format and definitions)

...

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-758 and EXP30-C

Independent( INT34-C, INT36-C, MEM30-C, MSC37-C, FLP32-C, EXP33-C, EXP30-C, ERR34-C, ARR32-C)

CWE-758 = Union( EXP30-C, list) where list =

• Undefined behavior that results from anything other than reading and writing to a variable twice without an intervening sequence point.

Bibliography

...

Image Added Image Added Image Added

References

Wiki Markup\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 5.1.2.3, "Program execution" \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.5, "Expressions" \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Annex C, "Sequence points" \[[Summit 05|AA. C References#Summit 05]\] Questions 3.1, 3.2, 3.3, 3.3b, 3.7, 3.8, 3.9, 3.10a, 3.10b, 3.11 \[[Saks 07|AA. C References#Saks 07]\]