bug-gnu-utils
[Top][All Lists]
Advanced

[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

Attachment: debug.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]