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)