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: <20273@crdgw1.crd.ge.com> Date: 5 Jun 91 16:02:11 GMT References: <1991Jun4.233928.5185@athena.mit.edu> <1991Jun5.014758.10616@wdl1.wdl.loral.com> Sender: news@crdgw1.crd.ge.com Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe) Distribution: usa Lines: 47 In article <1991Jun5.014758.10616@wdl1.wdl.loral.com>, bard@cutter.ssd.loral.com (J H Woodyatt) writes: |>In article <1991Jun4.233928.5185@athena.mit.edu>, scs@adam.mit.edu (Steve Summit) writes: |>|> In article fpb@ittc.wec.com (Frank P. Bresz) writes: |>|> > if ( (i=1) == (i=2) ) |>|> > |>|> >Is somebody wrong or is the behavior undefined? |>|> >Personal opinion: I think the behaviour is undefined by K&R anyway I can't |>|> >say for ANSI. |>|> |>|> Of course it's undefined. (It contains two side effects not |>|> separated by a sequence point.) |> |>Is this really undefined by ANSI? I suppose we need someone with the STANDARD to |>resolve this. (I'm politely assuming that there is a good reason for wanting to |>though I'm unable to think of one.) |> |>My 2nd edition K&R book says in the glossary (p.208) that the result of an |>assignment expression is the value that was stored in the lvalue after the |>assignment takes place. Thus, independent of order of evaluation, the above |>expression should always evaluate FALSE. (Or at least so say I.) Yes, it is undefined according to ANSI. It has nothing to do with order of evaluation, though. You are right about the value of each assignment expression, but that's not the point. The problem, as Steve pointed out, is that the value of "i" is modified twice between sequence points. As a result, all bets are off, since the Standard says that this is not allowed and that anything can happen if you do it. -Chris |>| |>| James Woodyatt VOICE: (415) 852-5429 |>| Space Systems/Loral (M/S G87) FAX: (415) 852-6286 |>| 3825 Fabian Way E-MAIL: bard@cutter.ssd.loral.com |>| Palo Alto, CA 9430 |>| ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com