Re: gawk number to string bug

[Andrew J. Schorr]

On Wed, Dec 21, 2005 at 04:48:08PM -0800, Paul Eggert wrote:
> "Andrew J. Schorr" <address@hidden> writes:
> 
> > why not simply
> > use snprintf("%.0f") to produce "%d"?
> 
> That thought occurred to me as well.  I think it would work.  You
> might have to be careful about infinity, though: it's not an integer
> but it compares equal to its floor.
> 
> Also, you'll need to size the output buffer correctly.
> 
> Care to write a patch?

Ugh, it looks to me as if there's currently a buffer overflow bug
in the way all the integer values are formatted (%d, %i, %o, etc.).
It looks like they are currently rendered into a fixed-size buffer
of 30 bytes.  This seems OK, but what if the precision is larger
than 30?  For example, suppose we have

  $ gawk 'BEGIN {printf "%.10d\n",5}'
  0000000005

This works fine.  But what if we increase that precision beyond 30?

  $ gawk 'BEGIN {printf "%.40d\n",5}'
  gawk: cmd. line:1: fatal error: internal error
  Abort (core dumped)

And valgrind shows:

  $ valgrind gawk 'BEGIN {printf "%.40d\n",5}'
  ==26433== Memcheck, a memory error detector for x86-linux.
  ==26433== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
  ==26433== Using valgrind-2.4.1, a program supervision framework for x86-linux.
  ==26433== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
  ==26433== For more details, rerun with: -v
  ==26433== 
  ==26433== Invalid write of size 1
  ==26433==    at 0x8056CED: format_tree (in /bin/gawk)
  ==26433==    by 0x8057349: do_sprintf (in /bin/gawk)
  ==26433==    by 0x8057468: do_printf (in /bin/gawk)
  ==26433==    by 0x8074D3C: interpret (in /bin/gawk)
  ==26433==    by 0x8074254: interpret (in /bin/gawk)
  ==26433==    by 0x8064DF7: main (in /bin/gawk)
  ==26433==  Address 0x30BFDF22 is not stack'd, malloc'd or (recently) free'd
  gawk: cmd. line:1: fatal error: internal error

So it seems that the current code is buggy.

The fix, of course, is to malloc a buffer and resize as necessary.
If we use snprintf("%.0f") for "%d", then we may need 2 buffers (one
for initial %.0f formatting, then another to render with thousands separators,
leading zeroes, etc.).

Regards,
Andy