Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: When do you use "if ( a = b )"? (was Re: Funny mistake)
Message-ID: <1991Mar23.103823.13491@thunder.mcrcim.mcgill.edu>
Date: 23 Mar 91 10:38:23 GMT
Article-I.D.: thunder.1991Mar23.103823.13491
References: <8148@rsiatl.Dixie.Com> <15481@smoke.brl.mil> <18401@lanl.gov>
Organization: McGill Research Centre for Intelligent Machines
Lines: 29

In article <18401@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:
> In article <11109@dog.ee.lbl.gov>, torek@elf.ee.lbl.gov (Chris Torek) writes:
>> [I]f your compiler generates different code for
>> 	if (a = b)
>> than for
>> 	a = b; if (a)
>> then your compiler is not worth what you paid for it.  [...]

(I will assume you meant to say "better" instead of simply "different".
On a SPARC, for example, there are at least three ways of implementing
a test-for-zero, none of which is significantly better or worse than
any other....)

> Even if it was _free_!  The above 'optimization' was present in
> Fortran compilers more than 30 years ago - and [...].

Comparing FORTRAN optimizers to C optimizers is generally comparing
apples and oranges.  FORTRAN contains restrictions on the programmer
that allow the optimizer vastly more latitude.

Not that it's really got much to do with this case.  If `a' has no
side-effects (being a volatile variable counts as having side-effects),
you both are quite right: there is no excuse for it.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu