🚀 go-pugleaf

In article <242@ssp1.idca.tds.philips.nl> dolf@idca.tds.PHILIPS.nl
(Dolf Grunbauer) writes:
>I even think this should be used on constructs like (x always becomes 0):
>    x = 0 * i++;     /* no auto-increment of i  */
>    x = 0 * foo();   /* no function call to foo */
>    x = 0 * foo(i++);/* no function call to foo, and no inc on i */

The point of Doug Gwyn's answer is that the pANS constrains the
effects of legal C code, not the actual code generated by the compiler.
In particular, in well-defined expressions (which includes `0 * x',
for all well-defined x), all side effects must take place.  So all
three of the above comments are wrong.

>A compiler warning seems appropriate to me on this point.

Here I agree.

>Another problem given by Georg was:
>    x = 0;
>    y = x * foo(i++);
>This is a bit harder. The side effects are hidden.

The side effects must always take place, whether optimised or not.  The
only thing an optimiser can do about

	x = 0 * i++;

is replace it with the sequence

	i++, x = 0;

(The `i++' can then be deleted if and only if i is a dead variable.)
Likewise, for

	x = 0 * foo();

the compiler can use

	foo(), x = 0;

and the call can only be deleted if foo() is a pure function (has no
side effects).  Most compilers do not even attempt to begin to consider
thinking about possibly looking for `function purity', although some
are starting to cogitate on the possibility of maybe doing so.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris