On Jul 8, 2013, at 4:43 AM, d...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
