Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!olivea!uunet!sdl.mdcbbs.com!daniel
From: daniel@sdl.mdcbbs.com
Newsgroups: comp.lang.c
Subject: Re: Evaluation of if's
Message-ID: <1991Jun16.160441.1@sdl.mdcbbs.com>
Date: 16 Jun 91 15:04:41 GMT
Article-I.D.: sdl.1991Jun16.160441.1
References: <20273@crdgw1.crd.ge.com> <1991Jun7.011938.11342@wdl1.wdl.loral.com>  <1991Jun13.184843.508@ulkyvx.bitnet>
Distribution: usa
Organization: Shape Data Ltd. (McDonnell Douglas M&E, Cambridge UK)
Lines: 99
Nntp-Posting-Host: shapeg
Nntp-Posting-User: daniel

Sorry about the previous posting, got news_edit logical wrong.

In article <1991Jun13.184843.508@ulkyvx.bitnet>, pgheit01@ulkyvx.bitnet writes:

> The statement if ((i = 1) == (i = 2)) is valid.  ANSI C evaluates conditions
> from left to right. *ALWAYS* ANSI C short-circuits a conditional statement
> *ALWAYS* (unless you tell it not to) That makes possible the type of statment


A quick perusal of my ANSI C spec indicates this is not correct.
Section 3.3  reads :-

    "Except as indicated by the syntax or otherwise specified later (for the
function call (), &&, ||, ?:, and comma operators), the order of evaluation
of subexpressions and the order in which side effects take place are both 
unspecified."

So you are correct about && but not about ==.

Section 3.3 also reads

    "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. (ftnote 25)"

"(ftnote 25)
This paragraph renders undefined statement expressions such as
    i = ++i + 1;
whilst allowing
    i = i + 1;
"                

On assigment operators the ansi standard states that 

   "An assigment expression has the value of the left operand after the 
assignment, but is not an lvalue""..."The side effect of updating the stored
 value of the left  operand shall occur between the previous and the next 
sequence point."

Now my copy of the standard is only a draft, so it may have been updated to
cover this rather nasty case. But my guess is that it hasn't. Anyway where 
does this leave us? My guess is that the value of the the expression in 
question is completely undefined (as is thevalue stored in i). A straw poll 
of the 'ANSI' C compilers in house yields the following results for the 
given code.

#include <stdio.h>

main(int argc,char **argv)
  {
    int i = 0;

    if ((i = 1) == (i = 2))
      {
        printf("Branch 1, i = %d\n",i);
      }
    else
      {
        printf("Branch 2, i = %d\n",i);
      }
  }

Sun :-
Branch 1, i = 2

Vax :-
Branch 1, i = 2  

Apollo :-
Branch 1, i = 2


However K&R variants produce different results

Sun :-
Branch 2, i = 1

Dec Risc:-
Branch 1, i = 2


Read these results as you will, to me it merely confirms that exepressions
with side effects should be avoided at all costs. Indeed we have developed 
an in House C variant which produces errors for these sorts of problems.

This case is an interesting example of hard to is to provide a 'complete' 
specification for a piece of code. After all an ANSI C compiler isn't
one of the largest pieces of software around. And, if we can't get the
specification for something as well defined (obviously not that well
defined as a compiler correct, where does that leave us with respect 
to some of the larger more complex software projects around 
(air traffic control, fly by wire ......)?

                                                              
Daniel Dignam                           Shape Data Limited (McDonnell Douglas)
 Internet: daniel@sdl.mdcbbs.com           46 Regent Street
     UUCP: ...!uunet!sdl.mdcbbs.com!daniel   Cambridge CB2 1DB
    Voice: +44 223 316673  Fax: +44 223 316931  United Kingdom