Evaluation of if's

[J H Woodyatt]

In article <1991Jun4.233928.5185 at athena.mit.edu>, scs at adam.mit.edu (Steve Summit) writes:
|> In article <FPB.91Jun4174400 at ittc.ittc.wec.com> fpb at 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.)

The fact that *my* compiler seems to overlook this wording is somewhat alarming
to me. I'd like to know what *else* it's willing to ignore, mangle or optimize
into oblivion incorrectly.

Which leads to an interesting question about portable programming. What fringy
kinds of things in a standard can one expect compilers to sometimes overlook and
thus be classifiable in the category of `Bad Programming Practice.'

 __________________________________________________________________
|
| James Woodyatt                 VOICE:  (415) 852-5429
| Space Systems/Loral (M/S G87)  FAX:    (415) 852-6286
| 3825 Fabian Way                E-MAIL: bard at cutter.ssd.loral.com
| Palo Alto, CA  9430
|