[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gawk number to string bug
From: |
Andrew J. Schorr |
Subject: |
Re: gawk number to string bug |
Date: |
Tue, 20 Dec 2005 09:06:32 -0500 |
User-agent: |
Mutt/1.4.1i |
On Mon, Dec 19, 2005 at 11:46:25PM -0800, Paul Eggert wrote:
> David Ellsworth <address@hidden> writes:
>
> > BEGIN { x=2**60; for(i=60;i<=65;i++) { printf "2^%d= %s %d %g\n",i,x,x,x;
> > x*=2}}
> > ...
> > The 2^64 value for %d is probably also a bug
>
> With my patch, on 64-bit Sparc you get:
>
> 2^60= 1152921504606846976 1152921504606846976 1.15292e+18
> 2^61= 2305843009213693952 2305843009213693952 2.30584e+18
> 2^62= 4611686018427387904 4611686018427387904 4.61169e+18
> 2^63= 9.22337e+18 9223372036854775808 9.22337e+18
> 2^64= 1.84467e+19 18446744073709551615 1.84467e+19
> 2^65= 3.68935e+19 3.68935e+19 3.68935e+19
>
> which is much more sane.
Hmmm, I must confess that I do not see how your patch addresses this
issue. The problem seems to be in builtin.c:format_tree(). Did your
patch change that function?
Running just the problem case:
gawk 'BEGIN {x=2^64; printf "2^%d= %s %d %g\n",64,x,x,x}'
on 32-bit x86 and 64-bit opteron, I see this:
32-bit x86:
2^64= 1.84467e+19 0 1.84467e+19
64-bit x86 (opteron):
2^64= 1.84467e+19 0 1.84467e+19
I then added some debug printf statements, as in the attached patch,
and the problem appears to be here:
tmpval = force_number(arg);
...
if (! (tmpval <= UINTMAX_MAX))
goto out_of_range;
That test should succeed (it IS out of range), but in fact it is failing,
because of the way UINTMAX_MAX is promoted to double precision. With
the debug printf statements in the attached patch, I see:
32-bit x86:
tmpval = 18446744073709551616, UINTMAX_MAX = 4294967295,
(double)UINTMAX_MAX = 18446744073709551616, (tmpval <= UINTMAX_MAX) = 1
uval = 0
64-bit x86 (opteron):
tmpval = 18446744073709551616, UINTMAX_MAX = 18446744073709551615,
(double)UINTMAX_MAX = 18446744073709551616, (tmpval <= UINTMAX_MAX) = 1
uval = 0
Perhaps I'm blind, but I don't see how your patch fixes this problem -- did you
change the definition of UINTMAX_MAX? Perhaps it just happens to work
properly on sparc 64-bit?
Regards,
Andy
debug.patch
Description: Text document
- Re: gawk number to string bug, (continued)
- Re: gawk number to string bug, Eli Zaretskii, 2005/12/19
- Re: gawk number to string bug, Andrew J. Schorr, 2005/12/19
- Re: gawk number to string bug, Eli Zaretskii, 2005/12/19
- Re: gawk number to string bug, Paul Eggert, 2005/12/19
- Re: gawk number to string bug, John Cowan, 2005/12/19
Re: gawk number to string bug, David Ellsworth, 2005/12/19
- Re: gawk number to string bug, Paul Eggert, 2005/12/20
- Re: gawk number to string bug, Paul Eggert, 2005/12/21
- Re: gawk number to string bug, Andrew J. Schorr, 2005/12/21
- Re: gawk number to string bug, Andrew J. Schorr, 2005/12/21
- Re: gawk number to string bug, Andrew J. Schorr, 2005/12/21
- Re: gawk number to string bug, Paul Eggert, 2005/12/21
- Re: gawk number to string bug, Andrew J. Schorr, 2005/12/22
- Re: gawk number to string bug, Andrew J. Schorr, 2005/12/23
- Re: gawk number to string bug, Andrew J. Schorr, 2005/12/23