Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde
From: bde@runx.oz.au (Bruce Evans)
Subject: Re: [386BSD] This MAXDOUBLE patch fixes some floating point coredumps
Message-ID: <1992Dec10.070938.26759@runx.oz.au>
Organization: RUNX Un*x Timeshare. Sydney, Australia.
References: <ByzFoo.Ix0@NeoSoft.com>
Date: Thu, 10 Dec 92 07:09:38 GMT
Lines: 32
In article <ByzFoo.Ix0@NeoSoft.com> karl@NeoSoft.com (Karl Lehenbauer) writes:
>The value of MAXDOUBLE in /usr/include/values.h will cause a floating point
>exception if a value is ever compared against it. I have verified this
>with gdb.
>*** /usr/karl/values.h Wed Dec 9 01:20:52 1992
>--- values.h Wed Dec 9 01:33:49 1992
>***************
>*** 108,116 ****
>...
>! #define MAXDOUBLE 1.79769313486231570e+308
^new value ^precise value would have 9 here
>...
>! #define MAXDOUBLE 1.79769313486231470E+308
^old value
This is very strange. The new value is larger than the old value yet it
is the old value that causes overflow bugs. Note that the diff is reversed.
On my system (I've changed a lot of related things but I don't think the
changes affect the result), gcc mungs the values by reading them with
atof and printing them with printf. The values passed to gas are both
increased by 100 in the last 3 digits. Not too bad. gas then somehow
does the right thing for the new value (although the new value has become
too large and should probably be converted to +Infinity) but it gives a
NaN (bit pattern 0xFFFFFFFF) for the old value (it should give the maximum).
<float.h> already uses a suitable value (600 in the last 3 digits; actually
without the 0's). This is a little too large so I've replaced it with the
570 value for safety.
--
Bruce Evans (bde@runx.oz.au)