Evaluation of if's

[daniel at sdl.mdcbbs.com]

In article <1991Jun13.184843.508 at ulkyvx.bitnet>, pgheit01 at ulkyvx.bitnet writes:
> In article <1991Jun7.232119.17834 at cs.ucla.edu>, jon at maui.cs.ucla.edu (Jonathan Gingerich) writes:
>> Having raised exactly this subject several months ago, let me point out
>> that both sides are making valid points.  There are two distinct things
>> going on:
>> 
>> 1. The description of the value of an assignment expression is sufficiently
>>    ambiguous in both K&RI and ANSI as to make the variability of
>> 	((i=1)==(i=2))
>>    a reasonable question.  This is not directly answered in the FAQ.  It is
>>    not a `order of evaluation' question. It is not obvious.
>> 
>> 2. There is no question that there is a rule in ANSI only, which says that
>>    expression which access the same location more than once are undefined.
>>    The above expression is undefined as is any other expression (to the
>>    best of my knowledge) that would illustrate a difference in the evaluation
>>    of an assignment expression.
>> 
>> Jon.
> 
> 
> AAAAAARRRRRGGGGHHHHH!
> 
> Here's how ANSI C works.  An expression (ANY EXPRESSION) returns a value in
> much the same way as a function returns a value.  The expression (i = 2)
> returns the value 2.  The expression (i = 1) returns the value 1.  No if's,
> and's or entry points or any of that stuff.
> 
> The statement if ((i = 1) == (i = 2)) is valid.  ANSI C evaluates conditions 
> from left to right. *ALWAYS* ANSI C short-circuits a conditional statement
> *ALWAYS* (unless you tell it not to) That makes possible the type of statment
> 
> if ((x != 0) && (1/x < 9))
>   STATMENT;
> (note that the inner sets of parentheses are not needed, and "< 9" could be
> changed to whatever you need to test. Also "x != 0" can just be "x".)
> 
> ANSI guarratees that the second statement will not be executed(and division by
> zero will not result) because the statment is false after the first condition
> if x == 0.
> 
> I did compile and run the code in question.  The assignments do take place. 
> i takes on the value 1 after the first condition is "tested", and i takes on
> the value 2 after the second condition is tested.  After the if-statement is
> executed, i is and will irrepairably be 2.
> 
> My C teacher just loved to slip in questions like this one to see if anyone
> knew the finer details of the precedence table. :-)
> 
> Paul == pgheit01 at ulkyvx.bitnet 
> 
> Disclaimer: How could U of L really accept anything this well-defined as an
> official policy?
-- 
Daniel Dignam                           Shape Data Limited (McDonnell Douglas)
 Internet: daniel at sdl.mdcbbs.com           46 Regent Street
     UUCP: ...!uunet!sdl.mdcbbs.com!daniel   Cambridge CB2 1DB
    Voice: +44 223 316673  Fax: +44 223 316931  United Kingdom