Re: gawk number to string bug

[Paul Eggert]

"Andrew J. Schorr" <address@hidden> writes:

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

Yes, that's another (and worse) behavior, but the patch that I
proposed catches that one as well, because on the host you're talking
about, DBL_FRACTION_BITS < CHAR_BIT * sizeof(long), which means the
safer test was used and the bug is avoided.

The behavior that I was talking about applies on Solaris 8 64-bit
sparc.  This platform converts the out-of-range value to the nearest
long representation.  On this platform, I think the patches that you
and Arnold proposed both suffer from the problem that I described in
my previous message.

> There is no mention of floating-point exceptions.

No, the standard says something worse than exceptions: it says the
behavior is undefined.  That means _anything_ can happen, including a
floating-point exception, or silently getting a completely wrong
answer (which is the behavior you observed on 64-bit opteron).  The
implementation is even allowed to dump core, or reformat your disk, or
whatever.

The patch that Arnold sent catches some of these undefined behaviors
that gawk 3.1.5 doesn't, but it still mishandles some corner cases on
some platforms.  The patch that I sent attempts to handle those corner
cases correctly too.

It is a tricky area, unfortunately.