Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The order of evaluation of subexpressions and the order in which side effects take place are frequently defined as unspecified behavior by the C Standard. Counterintuitively, unspecified behavior is where in behavior for which the standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance. Consequently, unspecified behavior can be a portability issue because different implementations can make different choices. If dynamic scheduling is used, however, there may not be a fixed-code execution sequence over the life of a process. Operations that can be executed in different sequences may in fact be executed in a different order.

...

Following are specific examples of situations in which the order of evaluation of subexpressions or the order in which side effects take place is unspecified:

...

This recommendation is related to EXP30-C. Do not depend on the order of evaluation between sequence pointsfor side effects, but it focuses on behavior that is nonportable or potentially confusing.

...

Consequently, the result of the following this noncompliant code example depends on unspecified behavior:

Code Block
bgColor#FFcccc
langc
#include <stdio.h>

int g;

int f(int i) {
  g = i;
  return i;
}

int main(void) {
  int x = f(1) + f(2);
  printf("g = %d\n", g);
  /* ... */
  return 0;
}

...

This code always results in g being assigned the value 2.

Exceptions

EXP10-C-EX1: The && and || operators guarantee left-to-right evaluation; there is a sequence point after the evaluation of the first operand.

EXP10-C-EX2: The first operand of a condition expression is evaluated; there is a sequence point after its evaluation. The second operand is evaluated only if the first compares unequal to 0; the third operand is evaluated only if the first compares equal to 0.

EXP10-C-EX3: There is a sequence point before function calls, meaning that the function designator, the actual arguments, and subexpressions within the actual arguments are evaluated before the function is invoked.

EXP10-C-EX4: The left operand of a comma operator is evaluated before the right operand is evaluated. There is a sequence point in between.

Note that whereas commas serve to delimit multiple arguments in a function call, these commas are not considered comma operators. Multiple arguments of a function call may be evaluated in any order, with no sequence points between each other.

Risk Assessment

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

EXP10-C

medium

Medium

probable

Probable

medium

Medium

P8

L2

Automated Detection

Tool

Version

Checker

Description

Astrée
Include Page
Astrée_V
Astrée_V
evaluation-order
multiple-volatile-accesses
Partially checked
Axivion Bauhaus Suite

Include Page
Axivion Bauhaus Suite_V
Axivion Bauhaus Suite_V

CertC-EXP10Fully implemented
CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

LANG.STRUCT.SE.IOE

Indeterminate Order of Evaluation
Compass/ROSE

 

 



Could detect violations of this recommendation by searching for the following pattern:

    • Any expression that calls two functions between the same sequence points
    • Those two functions both modify the value of a static variable
    • That static variable's value is referenced by code following the expression

Coverity

Include Page
Coverity_V
Coverity_V

EVALUATION_ORDER

Can detect the specific instance where a statement contains multiple side effects on the same value with an undefined evaluation order because the statement may behave differently with different compiler flags or different compilers or platforms

Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C0400, C0401, C0402, C0403, C0404, C0405, C3226, C3326


LDRA tool suite
Include Page
LDRA_V
LDRA_V
35 D

, 72 D

74 D
, 1 Q

, 134 S

Fully implemented

PRQA QA-C Include PagePRQA_VPRQA_V3226
Parasoft C/C++test
Include Page
Parasoft_V
Parasoft_V

CERT_C-EXP10-a
CERT_C-EXP10-b
CERT_C-EXP10-c
CERT_C-EXP10-d

The value of an expression shall be the same under any order of evaluation that the standard permits
Don't write code that depends on the order of evaluation of function arguments
Don't write code that depends on the order of evaluation of function designator and function arguments
Don't write code that depends on the order of evaluation of expression that involves a function call

PC-lint Plus

Include Page
PC-lint Plus_V
PC-lint Plus_V

564, 931

Partially supported

Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C: Rec. EXP10-C

Checks for situations where expression value depends on order of evaluation or side effects (rec. fully covered)

PVS-Studio

Include Page
PVS-Studio_V
PVS-Studio_V

V521, V681
RuleChecker
Include Page
RuleChecker_V
RuleChecker_V
evaluation-order
multiple-volatile-accesses
Partially checked
Partially implemented

A programmer could also violate the recommendation using dynamic memory passed to both functions, but that would be extremely difficult to detect using static analysis.

Related Vulnerabilities

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

Related Guidelines

SEI CERT C++
Secure
Coding Standard
EXP10
EXP50-CPP. Do not depend on the order of evaluation
of subexpressions or the order in which
for side effects
take place
ISO/IEC TR 24772:2013Operator Precedence/Order of Evaluation [JCW]
Side-effects and Order of Evaluation [SAM]
MISRA C:2012Rule 13.5 (required)

Bibliography

[ISO/IEC 9899:2011]Subclause 6.5, "Expressions"

...


...

Image Modified Image Modified Image Modified