Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!uunet!taumet!steve
From: steve@taumet.com (Stephen Clamage)
Newsgroups: comp.lang.c
Subject: Re: Evaluation of if's
Message-ID: <770@taumet.com>
Date: 18 Jun 91 16:33:28 GMT
Article-I.D.: taumet.770
References: <20273@crdgw1.crd.ge.com> <1991Jun7.011938.11342@wdl1.wdl.loral.com>  <1991Jun13.184843.508@ulkyvx.bitnet> <1991Jun16.160441.1@sdl.mdcbbs.com>
Distribution: usa
Organization: Taumetric Corporation, San Diego
Lines: 27

daniel@sdl.mdcbbs.com writes:

>    if ((i = 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...

Not necessarily, but one most certainly should avoid multiple side-effects
between sequence points.

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

This is not a difficulty of specification.  One could provide required
semantics for the above example, but it was a deliberate choice to
leave such things undefined.  Over-specification would force compiler
implementors to generate inefficient code in many cases in order to
satisfy the requirements of pathological programs like the above.

-- 

Steve Clamage, TauMetric Corp, steve@taumet.com