Newsgroups: comp.lang.c
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!convex!grogers
From: grogers@convex.com (Geoffrey Rogers)
Subject: Re: Evaluation of if's
Message-ID: <1991Jun05.135218.12838@convex.com>
Sender: usenet@convex.com (news access account)
Nntp-Posting-Host: mozart.convex.com
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
References: <FPB.91Jun4174400@ittc.ittc.wec.com> <1991Jun4.233928.5185@athena.mit.edu> <1991Jun5.014758.10616@wdl1.wdl.loral.com>
Distribution: usa
Date: Wed, 05 Jun 1991 13:52:18 GMT
Lines: 57

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.91Jun4174400@ittc.ittc.wec.com> fpb@ittc.wec.com (Frank P. Bresz) writes:
>|> >	if ( (i=1) == (i=2) )
>|> >
>|> >Is somebody wrong or is the behavior undefined?

The behavior of this expression is undefined. Section 3.3 states

Between the previous and next sequence point an object shall have its
stored value modified at most once by the evaluation of an expression.
Furthermore, the prior value shall be accessed only to determine the
value to be stored.[34]

Footnote 34:

34. This paragraph renders undefined statement expressions such as

	i = ++i + 1;

    while allowing

	i = i + 1;

Also you have an evaluation order problem here. Which subexpression do
you execute first i=1 or i=2? Again this is undefined.

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

Remember the operators = and == do  not have sequence points.

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

Since the behavior is undefined for this code fragment, you can expect any
two different compilers to gave you different results.

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

Anything behavior that is explicitly or implicitly defined as being
undefined (if the behavior is not defined, it is implicitly defined as
beening undefined, atleast this is what a compiler writer told me).

cheers

+------------------------------------+---------------------------------+
| Geoffrey C. Rogers   		     | "Whose brain did you get?"      |
| grogers@convex.com                 | "Abbie Normal!"                 |
| {sun,uunet,uiucdcs}!convex!grogers |                                 |
+------------------------------------+---------------------------------+