Newsgroups: comp.lang.c
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!lsuc!sq!msb
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Short circuit evaluation/expression rearrangement (2nd summary)
Message-ID: <1991Jun8.061646.1892@sq.sq.com>
Organization: SoftQuad Inc., Toronto, Canada
References: <1991Jun3.222214.20948@zoo.toronto.edu> <1991Jun5.231833.20542@sq.sq.com> <1991Jun6.171240.23388@cs.ucla.edu>
Date: Sat, 8 Jun 91 06:16:46 GMT
Lines: 28

>>>> [a + b + c]
>>>> What you DO know:     The addition of a and b will be made before c is
>>>>                       added to the result.
>>> 
>>> More precisely, what you know is that the program will *behave as if*
>>> things were done that way.  In particular, if the compiler can be
>>> sure that the order of evaluation will not affect behavior, it can
>>> use any order it pleases.
>>
>> Still more precisely, what you know is that *if* the program would *not*
>> cause an exception (e.g. overflow) if things were done that way, *then*
>> it will behave *as if* things were done that way.
> 
> No...  How can you distinguish the evaluation of a rearranged
> expression from an undefined evaluation which could be _anything_?

If you can distinguish it, then the compiler can't rearrange it --
*unless* your program, as written, would cause an exception.  If it
*would*, then we have undefined behavior and the compiler *can* rewrite
in any way it pleases -- including a way which would avoid the exception
and produce the answer you wanted, if such a way exists.

-- 
Mark Brader		     "It is impractical for the standard to attempt to
SoftQuad Inc., Toronto	      constrain the behavior of code that does not obey
utzoo!sq!msb, msb@sq.com      the constraints of the standard."  -- Doug Gwyn

This article is in the public domain.