Re: another -Wunsequenced topic

On Jul 8, 2013, at 4:43 AM, dt71_at_gmx.com wrote:

> Well, this turned out to be a semi-false alarm. A week ago, for a short time, there was a bug in Clang. There is no undefined behavior in
> 
>  ptr = func(++ptr);,

No, there is not.

However, this does have an implicit redundant store,
so changing it to

    ptr = func(ptr + 1);

is still a good idea, just not for the reason Clang was claiming.


> partially because a function call introduces a sequence point in C, but Clang did not respect this at that time. However,
> 
>  x = func1(++ptr) + func2(++ptr);
> 
> is compiler-dependent.

Code like this is badly broken.  The order of evaluation
here can even change across compiler versions (optimizers
use a variety of criteria to reorganize code, which can easily
change from version to version).

> Additionally, if func() turns out to be a macro, rather than a native function, then undefined behavior (due to unsequencedness) occurs.

Replacing functions with macros is a common way to
optimize code, which is yet another reason the idiom
above should generally be avoided.

> So in the end, Clang has accidentally pointed me to an irrelated bug, and induced some unnecessary code changes.

Not strictly necessary for correctness, but still good changes for the most part.

Tim