Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond
From: diamond@csl.sony.co.jp (Norman Diamond)
Newsgroups: comp.lang.c
Subject: Re: NaN traps
Message-ID: <10852@riks.csl.sony.co.jp>
Date: 18 Sep 89 10:37:03 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <1989Sep14.145420.5658@jarvis.csri.toronto.edu> <2110@munnari.oz.au> <14344@bloom-beacon.MIT.EDU>
Reply-To: diamond@riks. (Norman Diamond)
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 20

In article <14344@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael J Zehr) writes:

>I once wasted a lot of code dealing with something like:
>  if (data == 0) {zero_cnt++; continue;}
>  if NaN(data) {nan_cnt++; continue;}
>  do_something(data);
>if data was a bit pattern which was invalid, the
>comparison of it to 0 would change it's value to a particular number!!!

That seems like a somewhat illegal implementation.  I don't see an
"&" in front of data, and you didn't say you're using C++.  So the
NaN function can only get its hands on a COPY of data, and change
its COPY to a different value (according to K&R-*, ANSI, Version 6, etc.)

--
-- 
Norman Diamond, Sony Corporation (diamond@ws.sony.junet)
  The above opinions are inherited by your machine's init process (pid 1),
  after being disowned and orphaned.  However, if you see this at Waterloo or
  Anterior, then their administrators must have approved of these opinions.