Re: [9fans] a bug in awk?

Re: [9fans] a bug in awk?

[erik quanstrom]

> 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

Re: [9fans] a bug in awk?

[Russ Cox]

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

for one thing, the regular (= plan 9 libc) strtod doesn't set errno.

russ

Re: [9fans] a bug in awk?

[erik quanstrom]

>> is there some reason that the regular strtod is unsuitable for
>> ape?
>
> for one thing, the regular (= plan 9 libc) strtod doesn't set errno.

i didn't say exactly what i ment.  would adding
errno setting and potentially altering return values
(i'm not clear if this is necessary) be sufficient
to use the libc strtod with ape?

- erik

Re: [9fans] a bug in awk?

[Tharaneedharan Vilwanathan]

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
>
>
>

Re: [9fans] a bug in awk?

[erik quanstrom]

> 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...

not exactly.  i believe this is an ape problem.  i don't think that c89 or
c99 allow a strtod to result in an exception.

[...]
acid: cont()
	11260359 d05544897ff642ca36e58174bc753b0f3382b793   0
3
8192 Jan  9 18:09
4
              11258672 5946903e318d3596c21e35b42a13c1dea5fd32cc   0
7627: math coprocessor error	strtod+0x3b5	FMOVD	rv+0x44(SP),F0
Notes pending:
	sys: fp: numeric overflow fppc=0x16852 status=0xb8a8
acid: stk()
strtod(s00=0x4f0a4,se=0xdfffee24)+0x3b5 /sys/src/ape/lib/ap/stdio/strtod.c:473
is_number(s=0x4f09d)+0x55 /sys/src/cmd/awk/lib.c:703
fldbld()+0x16c /sys/src/cmd/awk/lib.c:333
getnf(a=0x5a90c)+0xe /sys/src/cmd/awk/run.c:439
execute(u=0x5a8fc)+0xbb /sys/src/cmd/awk/run.c:157

- erik

Re: [9fans] a bug in awk?

[John Stalker]

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...
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] a bug in awk?

[Tharaneedharan Vilwanathan]

hi lucio,

so, it tries to interpret as a floating-point no and goes for a toss!

thanks for the quick response.

regards
dharani

On Fri, Jan 9, 2009 at 10:26 PM,  <lucio@proxima.alt.za> wrote:
>>               11258672 5946903e318d3596c21e35b42a13c1dea5fd32cc   0
>
> Note the 5946903e318 which AWK may mistakenly treat as a floating
> point constant.  Now to figure how to prevent such errors...
>
> ++L
>
>
>

Re: [9fans] a bug in awk?

[lucio]

>               11258672 5946903e318d3596c21e35b42a13c1dea5fd32cc   0

Note the 5946903e318 which AWK may mistakenly treat as a floating
point constant.  Now to figure how to prevent such errors...

++L

[9fans] a bug in awk?

[Tharaneedharan Vilwanathan]

hi,

while i was playing with venti archive, i found something interesting.

i used dumpvacroots.new (from contrib) and for some reason, awk bailed
out with floating point error whenever it saw a line with a specific
root score.

here are the two sample lines (i used customized printarena.c which
prints the date for me at the end):

              11260359 d05544897ff642ca36e58174bc753b0f3382b793   0
8192 Jan  9 18:09
              11258672 5946903e318d3596c21e35b42a13c1dea5fd32cc   0
8192 Jan  9 18:09

awk seems to be okay with the first line but not the second line.

here is the output when i use awk:

mill# awk ' { print $0; print NF}' /tmp/out1.dat
              11260359 d05544897ff642ca36e58174bc753b0f3382b793   0
8192 Jan  9 18:09
7
              11258672 5946903e318d3596c21e35b42a13c1dea5fd32cc   0
8192 Jan  9 18:09
awk: floating point exception 6
 input record /tmp/out1.dat:2
 source line 1

i figured that:

- awk runs fine if i dont print NF. (so, it parses the line on-demand
and parsing fails?)
- awk doesnt seem to like the score 5946....32cc. If I change that
score to something else and rerun, it seems to be fine.

to confirm that this is a plan9 specific awk issue, i tried the same
with my Mac machine. it seems to be okay:

$ awk ' { print $0; print NF }' out1.dat
              11260359 d05544897ff642ca36e58174bc753b0f3382b793   0
8192 Jan  9 18:09
7
              11258672 5946903e318d3596c21e35b42a13c1dea5fd32cc   0
8192 Jan  9 18:09
7

what could be the issue? any clues?

i initially thought my venti data got corrupted but i am now convinced
that this is something else, since i was also able to reliably archive
data.

thanks
dharani