Re: gawk number to string bug

[Andrew J. Schorr]

On Mon, Dec 19, 2005 at 01:12:40PM -0800, Paul Eggert wrote:
> Neither your patch nor Arnold's suffice, unfortunately.
> 
> With your patch, suppose long is 64 bits and double is 64-bit IEEE
> double.  The string "9223372036854775808" (which is 2**63) can be
> converted to double exactly, without loss of information; but since
> 2**63 is too big for long, it is converted to LONG_MAX when you
> convert it to long.  So far so good, but now when you compute
> 
>   if ((AWKNUM)(num) != s->number)
> 
> converting LONG_MAX to AWKNUM yields 9223372036854775808 again, since
> 2**63 is the double value that is closest to LONG_MAX.  So the
> comparison is equal, and gawk then incorrectly thinks that no
> conversion problem had occurred.

Hmmm, I'm sure you understand this better than I do, but I don't
seem to see the behavior you claim.

On a 64-bit opteron box, I see the following behavior with my patch (based
on some printfs that I inserted).  If the node's floating-point value
is  9223372036854775808, then the long value that it is converted into
is -9223372036854775808.  As a result, the comparison with the double
value fails, and it is formatted as floating point, not as a long.  So I see:

   $ ./gawk 'BEGIN {x = 9223372036854775808 ; print x; print x/1e18}'
   9.22337e+18
   9.22337

as compared to the installed gawk:

   $ /bin/gawk 'BEGIN {x = 9223372036854775808 ; print x; print x/1e18}'
   -9223372036854775808
   9.22337

Perhaps some different input value would demonstrate the problem
that you fear?

Regards,
Andy