Return to BSD News archive
Xref: sserve comp.unix.bsd:11579 comp.unix.xenix.sco:6809
Newsgroups: comp.unix.bsd,comp.unix.xenix.sco
Path: sserve!manuel.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde
From: bde@runx.oz.au (Bruce Evans)
Subject: Re: 386BSD: cc1 got fatal signal 6
Message-ID: <1993Mar1.041950.14393@runx.oz.au>
Organization: RUNX Un*x Timeshare. Sydney, Australia.
References: <1993Feb16.215658.29848@runx.oz.au> <1993Feb25.093706.26305@robobar.co.uk> <ARNEJ.93Feb25172304@chanur.imf.unit.no>
Date: Mon, 1 Mar 93 04:19:50 GMT
Lines: 55
In article <ARNEJ.93Feb25172304@chanur.imf.unit.no> arnej@imf.unit.no (Arne Henrik Juul) writes:
>...
>It seems that printf() is broken while sscanf and atof are OK.
>
>Test program with (correct) constants:
>
>#undef DBL_MIN
>#define DBL_MIN 2.2250738585072014e-308
>
>#undef DBL_MAX
>#define DBL_MAX 1.7976931348623157e+308
>...
>[test program deleted - just print the numbers in %23.17e and hex formats]
Actually, gcc-2.3.3 and gcc-1.39 -O give the correct hex values
0010000000000000 (DBL_MIN)
7fefffffffffffff (DBL_MAX)
while gcc-1.39 [not -O] gives
000fffffffffffff (DBL_MIN) (nope, 1 bit innacuracy)
7ff0000000000002 (DBL_MAX) (nope, gas has corrupted it to a NaN)
The difference is because gcc-1.39 [not -O] converts the numbers 4 times
(atof input, printf output, gas input, gas output) while the other compilers
only convert the numbers once (atof input). The printf output is inaccurate
and both atof input and gas input are broken on out-of-bounds numbers.
I use the values:
#define DBL_MAX 1.7976931348623147e+308
#define HUGE_VAL 1.7976931348623157e+308
To find suitable values, just start from the correct value and reduce it in
small steps until working value is found. The highest working value seems
to be:
#define DBL_MAX 1.7976931348623153e+308
Even the correct ...57 value might work if -O is always used!
The correct value may be found easily using infinite precision arithmetic:
DBL_MIN: echo 5^1022 | bc
DBL_MAX: echo "2^(1023-52) * (2^53-1)" | bc
I think the patchkit uses the ...47 value for both DBL_MAX and HUGE_VAL.
HUGE_VAL should really be IEEE +infinity (bit pattern 0x7ff0000000000000).
The can be implemented as #define HUGE_VAL __huge_val() where __huge_val()
loads the bit pattern. I haven't tried this under 386BSD. It may
interact with the other bugs, and the library mostly doesn't return
HUGE_VAL for range errors like it's supposed to.
--
Bruce Evans (bde@runx.oz.au)