...
This rule means that statements such as
Code Block |
---|
|
i = i + 1;
a[i] = i;
|
have well-defined behavior, while statements like
Code Block |
---|
|
/* 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;
|
...
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.
Code Block |
---|
|
a = i + b[++i];
|
If i
was equal to 0 before the statement, the statement may result in the following outcome:
Or it may result in the following outcome:
Compliant Solution
These examples are independent of the order of evaluation of the operands and can only be interpreted in one way.
Code Block |
---|
|
++i;
a = i + b[i];
|
Or alternatively:
...
The order of evaluation for function arguments is unspecified.
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.
...
This solution is appropriate when the programmer intends for both arguments to func()
to be equivalent.
Code Block |
---|
|
i++;
func(i, i);
|
This solution is appropriate when the programmer intends for the second argument to be one greater than the first.
Code Block |
---|
|
j = i++;
func(j, i);
|
Risk Assessment
...