🚀 go-pugleaf

In article <10885@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <1237@gmdzi.UUCP> wittig@gmdzi.UUCP (Georg Wittig) writes:
>>	0 * x			(x non-constant)
>>	0 / x
>>	x << (100000000L)
>>	etc.
>>Does (p)ANSI C say anything about which code should be generated for such
>>expressions?
>This falls naturally out of the specification.  The operands ARE evaluated,
>so if `x' has side-effects they do occur.  If evaluation would produce what
>the Standard labels as "undefined behavior", then the implementation can do
>anything it likes including taking short cuts, but in cases where the
>behavior is well defined the only short cuts permitted are those that
>produce the same results as doing it the long way.

How can you tell what will happen when 'doing it the long way' ? Even C
has contructs which behave quite different from using the short cut and
the long way, e.g. the next construct won't work the long way:
      if ((i != 0) && (x/i > 0))     /* assume i and x integers */
(Yes I know the && is defined to always use the short cut, this example is
used only to make my point clear, at least I hope :-).
So I would say (from a compiler builders standpoint of view): 
   once you see a way to determind the result of an expression on compile
   time then use this result, and do not execute the expression on runtime.
This means that in the examples of Georg, I would like to have the results
of the expressions (i.e. 0) in my code.
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 */
A compiler warning seems appropriate to me on this point.
Another problem given by Georg was:
    x = 0;
    y = x * foo(i++);
This is a bit harder. The side effects are hidden. I hink in this case the
function has to be called and the i incremented. I do not think it is allowed
to compile this last line as:
   if (x != 0) foo(i++);
   y = 0;
-- 
Dolf Grunbauer          Tel: +31 55 432764  Internet dolf@idca.tds.philips.nl
Philips Telecommunication and Data Systems  UUCP ....!mcvax!philapd!dolf
Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands