Evaluation of if's

[Christopher R Volpe]

In article <1991Jun13.184843.508 at ulkyvx.bitnet>, pgheit01 at ulkyvx.bitnet writes:
|>
|>Here's how ANSI C works.  An expression (ANY EXPRESSION) returns a value in
|>much the same way as a function returns a value. 

Really? Expressions "yield" values. Functions "return" them. The mechanism
is probably not all that similar, although this is an unimportant point
right now.

|> 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.

Not relevant.

|>
|>The statement if ((i = 1) == (i = 2)) is valid.  

No it's not. RTFS.

|>ANSI C evaluates conditions 
|>from left to right.

No. It evaluates the left operand of a "||" or "&&" operator before
the right operand. But it's perfectly free to evaluate the right operand of
"==" before the left operand. Of course, order of evaluation is not 
even the issue here anyway. The issue is assignment semantics. An
implementation
is free to do the following operations:

Store 2 in i.
Store 1 in i.
Get value of i as first operand.
Get value of i as second operand. 
Compare fist operand to second operand.

|> *ALWAYS* ANSI C short-circuits a conditional statement

Irrelevant. There is no short circuiting in "((i=1) == (i=2))".

|>*ALWAYS* (unless you tell it not to) 

How do you tell it not to short circuit "&&" or "||"??? You can't.

|>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".)

What are you talking about? The above statement is correct, but has absolutely
nothing to do with this discussion.

|>
|>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.

Again, so what?

|>I did compile and run the code in question.  The assignments do take place. 

Oh good. "Proof by example". 

|>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.

Lucky you. The behavior is undefined. It can do anything, including what
you'd like it to do. Just don't rely on it.

|>My C teacher just loved to slip in questions like this one to see if anyone
|>knew the finer details of the precedence table. :-)

Good. Now that you're an expert on operator precedence you can learn the
finer details of assignment semantics.

                                                    
==================
Chris Volpe
G.E. Corporate R&D
volpecr at crd.ge.com