Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!tada
From: tada@athena.mit.edu (Michael J Zehr)
Newsgroups: comp.lang.c
Subject: NaN traps
Message-ID: <14344@bloom-beacon.MIT.EDU>
Date: 16 Sep 89 17:27:23 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <1989Sep14.145420.5658@jarvis.csri.toronto.edu> <2110@munnari.oz.au>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: tada@athena.mit.edu (Michael J Zehr)
Organization: Massachusetts Institute of Technology
Lines: 22

In article <2110@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
>This will
>give similar trouble on machines with VAX arithmetic (some bit patterns
>when considered as floats are "invalid operands" which trap when/if you
>touch them) and on machines with IEEE arithmetic and traps enabled (the
>IEEE default is _not_ to enable traps!) where some bit patterns (called
>Signalling NaNs) trap.

I once wasted a lot of code dealing with something like: (hopefully this
example will save someone else time recognizing it in the future...)

if (data == 0) {zero_cnt++; continue;}
if NaN(data) {nan_cnt++; continue;}
do_something(data);

the problem was that do_something() was getting garbage results.  the
reason was that if data was a bit pattern which was invalid, the
comparison of it to 0 would change it's value to a particular number!!!
(i think it was the maximum value for it's data type, but i never
verified that.)  the solution, of course, was to switch the two lines.

-michael j zehr