From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1f008c20c3fcaf5ebcc59a63642a32fb@quanstro.net>
To: 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat, 10 Jan 2009 16:45:15 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] a bug in awk?
Topicbox-Message-UUID: 7fa84de4-ead4-11e9-9d60-3106f5b1d025

> For what it's worth, bwk awk does not have this problem, so the error
> must be in code introduced later.
>
>> Note the 5946903e318 which AWK may mistakenly treat as a floating
>> point constant.  Now to figure how to prevent such errors...

from the better than nothin' department ...

i have an inelegant couple of lines that prevent overflow.

one would expect that for a postitive exponent that if
	nwholedigits + exponent - 1 > the maximum exp.
then you'll have an overflow.  (ideally one should do this
computation in ieee space, but that's not what the code
does.)  i put this simple test in the natural place and
it seems to avoid the floating point exception (tested on intel
machines).  the problem seems to be that the code deals
with very small overflows, but isn't prepared to deal with
a number that's going to overflow by a lot.  in this case,
we're 1^(10 + 6) too big.

; diffy strtod.c
396a397,398
> 		if(nd0 + e1 - 1> DBL_MAX_10_EXP)
> 			goto ovfl;
431a434,435
> 		if(e1 - (nd-nd0) > DBL_MAX_10_EXP)
> 			goto undfl;

is it even legal to return DBL_MAX for numbers that should
be +Inf or DBL_MIN for numbers that should yield -Inf?

is there some reason that the regular strtod is unsuitable for
ape?

- erik