CertC-EXP30¶

Do not depend on the order of evaluation for side effects

Required inputs: IR

Evaluation of an expression may produce side effects. At specific points during execution, known as sequence points, all side effects of previous evaluations 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 C Standard, 6.5, paragraph 2 [ ISO/IEC 9899:2011], 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 end of a full declarator
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
- 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 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, and also between any call to a comparison function and any movement of the objects passed as arguments to that call

Furthermore, Section 6.5.16, paragraph 3 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.

This rule means that statements such as

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

have defined behavior, and statements such as the following do 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;

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.2.2, paragraph 10 [ ISO/IEC 9899:2011]

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 undefined:

#include <stdio.h>

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

Compliant Solution

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

#include <stdio.h>

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

Alternatively:

#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 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 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, which can lead to unexpected program behavior.

Rule	Severity	Likelihood	Remediation Cost	Priority	Level
EXP30-C	Medium	Probable	Medium	P8	L2

Related Guidelines

Taxonomy	Taxonomy item	Relationship
CERT C	EXP50-CPP. Do not depend on the order of evaluation for side effects	Prior to 2018-01-12: CERT: Unspecified Relationship
CERT Oracle Secure Coding Standard for Java	EXP05-J. Do not follow a write by a subsequent write or read of the same object within an expression	Prior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TR 24772:2013	Operator Precedence/Order of Evaluation [JCW]	Prior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TR 24772:2013	Side-effects and Order of Evaluation [SAM]	Prior to 2018-01-12: CERT: Unspecified Relationship
MISRA C:2012	Rule 13.2 (required)	CERT cross-reference in MISRA C:2012 - Addendum 3
CWE 2.11	CWE-758	2017-07-07: CERT: Rule subset of CWE

Bibliography

[ ISO/IEC 9899:2011]	6.5, "Expressions" 6.5.2.2, "Function Calls" Annex C, "Sequence Points"
[ Saks 2007]
[ Summit 2005]	Questions 3.1, 3.2, 3.3, 3.3b, 3.7, 3.8, 3.9, 3.10a, 3.10b, and 3.11

Excerpt from SEI CERT C Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems (2016 Edition) and SEI CERT C Coding Standard [https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp30-c], Copyright (C) 1995-2026 Carnegie Mellon University. See section 9.4. "3rd-Party Licenses" in the documentation for full details.

Possible Messages

Key	Text	Severity	Disabled
unsequenced_atomics	Unsequenced accesses of _Atomic-qualified objects	None	False
unsequenced_call_atomic	Function calls unsequenced with atomic access	None	False
unsequenced_call_read	Variable read here is also written in unsequenced function call	None	False
unsequenced_call_volatile	Function calls unsequenced with volatile access	None	False
unsequenced_call_write	Variable written here is also accessed in unsequenced function call	None	False
unsequenced_calls	Unsequenced function calls	None	False
unsequenced_read_write	Unsequenced read and write accesses	None	False
unsequenced_volatile_and_atomic	Unsequenced volatile access and atomic access	None	False
unsequenced_volatile_and_non_volatile	Unsequenced volatile and non-volatile access to same memory location	None	True
unsequenced_volatiles	Unsequenced volatile accesses	None	False
unsequenced_writes	Unsequenced writes	None	False

Options¶

This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity
The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions

ignore_exceptions¶

ignore_exceptions : bool = False

Ignore possible exceptions in the computation of side effects (this option only has an effect if report_calls is enabled).

ignore_unknown_code¶

ignore_unknown_code : bool = False

Ignore unsequenced function calls involving "Unknown effect". This effect can occur when the definition of a function is unavailable to the analysis (this option only has an effect if report_calls is enabled).

ignore_unknown_memory¶

ignore_unknown_memory : bool = False

Ignore reading from or writing to memory that isn't tracked by this rule (this option only has an effect if report_calls is enabled).

report_calls¶

report_calls : bool = True

If True, reports unsequenced function calls.

Axivion Suite 7.12.0

Navigation

CertC-EXP30¶

Noncompliant Code Example

Compliant Solution

Noncompliant Code Example

Compliant Solution

Noncompliant Code Example

Compliant Solution

Risk Assessment

Related Guidelines

Bibliography

Options¶

ignore_exceptions¶

ignore_unknown_code¶

ignore_unknown_memory¶

report_calls¶