Date: Mon, 8 Jul 2013 21:40:42 -0700 From: Tim Kientzle <tim@kientzle.com> To: dt71@gmx.com Cc: freebsd-current@freebsd.org Subject: Re: another -Wunsequenced topic Message-ID: <6AC1186D-3D9C-4B7A-B5E4-4EA9CB120517@kientzle.com> In-Reply-To: <51DAA5FE.4040505@gmx.com> References: <51CEEC34.2010308@gmx.com> <51D03D27.3020100@gmx.com> <51DAA5FE.4040505@gmx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 8, 2013, at 4:43 AM, dt71@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
>=20
> ptr =3D func(++ptr);,
No, there is not.
However, this does have an implicit redundant store,
so changing it to
ptr =3D 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,
>=20
> x =3D func1(++ptr) + func2(++ptr);
>=20
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6AC1186D-3D9C-4B7A-B5E4-4EA9CB120517>