large integer formatting problems

[Andrew J. Schorr]

Hi,

This was discussed initially over a year ago, and we merged a patch
into xgawk to address this.  But I just tested on Savannah gawk-stable,
and the problems persist.  I am attaching the test case we use
in xgawk.  And here's what I see with a 64-bit linux system running
savannah gawk-stable on this test case:

   bash-3.1$ ./gawk --version | head -1
   GNU Awk 3.1.5c

   bash-3.1$ ./gawk -f test/intformat.awk 
   (sprintf(0x%x,2^64) = 0x0)-1.84467e+19 = -1.84467e+19
   (sprintf(0%o,2^64) = 00)-1.84467e+19 = -1.84467e+19
   (sprintf(%d,2^64) = 0)-1.84467e+19 = -1.84467e+19
   3 -3 17
   000000000000000000000000000000000000000000000000000001

Whereas with the patched xgawk, we get this output:

   bash-3.1$ xgawk -f test/intformat.awk 
   3 -3 17
   0000000000000000000000000000000000000000000000000000001

Also, note that savannah is printing some NUL (\0) chars on the 
last line ('printf "%.55d\n",1'), and printing the wrong number of zeroes:

   bash-3.1$ ./gawk -f test/intformat.awk  | tail -1 | od -c
   0000000  \0  \0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
   0000020   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
   *
   0000060   0   0   0   0   0   0   0   1  \n
   0000071

I know this was all discussed long ago, but I can't quite remember the
resolution.  Is savannah gawk's behavior considered OK, or should it
be patched?

Regards,
Andy

intformat.awk
Description: Text document

intformat.ok
Description: Text document