Re: [9fans] a bug in awk?

["Tharaneedharan Vilwanathan" <vdharani@gmail.com>]

hi erik,

i had a temp code in dumvacroots.new:

	...
        rc |
	awk '/5946903e/	{ next; }
		$3==16 {printf("%s\n", $0)}'

which i removed it now, built awk with your fix in place and tried.
the problem is fixed now.

thanks for the fix.

regards
dharani

On Sat, Jan 10, 2009 at 1:45 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> 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
>
>
>