Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!camelback!volpe From: volpe@camelback.crd.ge.com (Christopher R Volpe) Newsgroups: comp.lang.c Subject: Re: Evaluation of if's Message-ID: <20575@crdgw1.crd.ge.com> Date: 14 Jun 91 13:30:18 GMT References: <20273@crdgw1.crd.ge.com> <1991Jun7.011938.11342@wdl1.wdl.loral.com> <1991Jun7.232119.17834@cs.ucla.edu> <1991Jun13.184843.508@ulkyvx.bitnet> Sender: news@crdgw1.crd.ge.com Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe) Distribution: usa Lines: 84 In article <1991Jun13.184843.508@ulkyvx.bitnet>, pgheit01@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@crd.ge.com