CERT C++: EXP50-CPP

Do not depend on the order of evaluation for side effects

expand all in page

Description

Rule Definition

Do not depend on the order of evaluation for side effects.¹

Polyspace Implementation

The rule checker checks for Expression value depends on order of evaluation.

Examples

expand all

Expression value depends on order of evaluation

Issue

The issue occurs when the value of an expression is not the same depending on the order of evaluation of the expression.

An expression can have different values under the following conditions:

The same variable is modified more than once in the expression, or is both read and written.
The expression allows more than one order of evaluation.

Therefore, the rule checker forbids expressions where a variable is modified more than once and can cause different results under different orders of evaluation. The rule checker also detects cases where a volatile variable is read more than once in an expression.

Risk

If an expression results in different values depending on the order of evaluation, its value becomes implementation-defined.

Example — Variable Modified More Than Once in Expression

int a[10], b[10];
#define COPY_ELEMENT(index) (a[(index)]=b[(index)])

void main () {
    int i=0, k=0;

    COPY_ELEMENT (k);         /* Compliant */
    COPY_ELEMENT (i++);       /* Noncompliant  */
}

In this example, the rule is violated by the statement COPY_ELEMENT(i++) because i++ occurs twice and the order of evaluation of the two expressions is unspecified.

Example — Variable Modified and Used in Multiple Function Arguments

void f (unsigned int param1, unsigned int param2) {}

void main () {
    unsigned int i=0;
    f ( i++, i );                 /* Non-compliant */ 
}

In this example, the rule is violated because it is unspecified whether the operation i++ occurs before or after the second argument is passed to f. The call f(i++,i) can translate to either f(0,0) or f(0,1).

Example — Multiple volatile Objects in an Expression

volatile int a, b;
int mathOp(int x, int y);

int foo(void){
	int temp = mathOp(5,a) + mathOp(6,b);//Noncompliant
	return temp * mathOp(a,a);//Noncompliant
}

In this example, this rule is violated twice.

The declaration of temp uses two volatile objects in the expression. Because the value of volatile objects might change at any time, the expression might evaluate to different values depending on the order of evaluation. Polyspace^® flags the second volatile object in the expression.
The return statement uses the same volatile object twice. Because the expression might have different results depending on the order of evaluation, Polyspace raises this defect.

Check Information

Group: 02. Expressions (EXP)

Version History

Introduced in R2019a

expand all

R2023b: Correctly sequenced double writes no longer reported as violation

The rule checker does not report violations of this rule when you use correctly sequenced double writes:

i=i=0; //Compliant
j = j = ++j;//Compliant

R2021b: Checker reports violation when global variable is written and reused in same expression

The checker shows more accurate results. For instance:

The checker reports only one violation when a variable is written and reused within the same expression. Previously, two violations were reported.
The checker detects violations involving global variables, for instance, when the same global variable is written and reused in an expression.

¹ This software has been created by MathWorks incorporating portions of: the “SEI CERT-C Website,” © 2017 Carnegie Mellon University, the SEI CERT-C++ Web site © 2017 Carnegie Mellon University, ”SEI CERT C Coding Standard – Rules for Developing safe, Reliable and Secure systems – 2016 Edition,” © 2016 Carnegie Mellon University, and “SEI CERT C++ Coding Standard – Rules for Developing safe, Reliable and Secure systems in C++ – 2016 Edition” © 2016 Carnegie Mellon University, with special permission from its Software Engineering Institute.

ANY MATERIAL OF CARNEGIE MELLON UNIVERSITY AND/OR ITS SOFTWARE ENGINEERING INSTITUTE CONTAINED HEREIN IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

This software and associated documentation has not been reviewed nor is it endorsed by Carnegie Mellon University or its Software Engineering Institute.