question to examples of rule 6.12.2

[Manni]

Hi

In Rule 12.2

nested assignment statements
Assignments nested within expressions cause additional side effects. The best way to avoid any chance of this leading to a dependence on order of evaluation is to not embed assignments within expressions.

For example, the following is not recommended:
x = y = y = z / 3 ;
x = y = y++;

I don't understand, what could go wrong here:
1. x = y = y = z / 3 ;
2. x = y = y++;

If x = 1, y = 2, z = 3, I would say,

- for 1. the result for x is everytime 1
- for 2. the result for x is everytime 3

What could a compiler make different here?

thanks

[bmerkle]

Hi Manni,

2. x = y = y++;

the problem with this is that the evaluation order of y = y++ is not defined.
So the result depends if you compiler evaluates from left_to_right or from right_to_left, and as this is not defined by the ISO standard, the behaviour of your statement/program is undefined.

kind regards,
Bernhard.

[misra-c]

MISRA-C meeting 22-8-2006

Code:

x = y = y = z;

There is both human confusion and undefined behaviour associated with nested assignment statements.

See ISO C 9899:1990 6.3 para. 2.

Keep it simple and write

Code:

y = z;
x = y;