Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ames!xn.ll.mit.edu!mit-eddie!andante!alice!ark
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: When do you use "if ( a = b )"? (was Re: Funny mistake)
Message-ID: <20137@alice.att.com>
Date: 29 Mar 91 15:47:11 GMT
References: <1991Mar18.195351.11985@unlv.edu> <11109@dog.ee.lbl.gov> <15053@ganymede.inmos.co.uk> <3482@inews.intel.com>
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 39

In article <3482@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes:

> No compiler
> in the world won't make
> 	a=b
> 	if(a)
> the same as
> 	if(a=b)
> as far as any user can tell

A while ago I remember a big argument about the difference between
code generated by a particular compiler for this:

	a=b-c;
	if(a)

and for this

	if(a=b-c)

In the first case, the compiler dutifully stored b-c in a and
then tested the value of a.  In the second, it generated a
three-address subtract instruction to put the result in a
and then did a conditional jump based on the condition code
resulting from the subtract.  You'd think those would have the
same effects, wouldn't you?

It turned out that the effects differed if the subtract
caused an overflow (call it underflow if you like) with a
zero result.  In the first case, the test would show that
a==0.  In the second, the condition code would show an
overflow.  Overflow is not the same as zero, so the test
would fail.

I believe that this behavior on the part of the compiler
is entirely reasonable.
-- 
				--Andrew Koenig
				  ark@europa.att.com