MISRA Discussion Forums
question to examples of rule 6.12.2 - Printable Version

+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA-C: 2004 rules (https://forum.misra.org.uk/forumdisplay.php?fid=17)
+---- Forum: 6.12 Expressions (https://forum.misra.org.uk/forumdisplay.php?fid=39)
+---- Thread: question to examples of rule 6.12.2 (/showthread.php?tid=277)

question to examples of rule 6.12.2 - Manni - 23-06-2006

Hi

In Rule 12.2
Quote: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 - 24-07-2006

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 - 22-08-2006

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;