Re: gawk number to string bug

[Paul Eggert]

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

> I had to add an explicit test for this case; perhaps someone else
> can see a more elegant way.

I had trouble applying your latest patch to gawk 3.1.5; see below.
Can you please resend it, so that it can be applied to 3.1.5?  Thanks.

> I do agree with Paul that it will not give perfect results in all
> cases (seems to be off by one sometimes on sparc for huge values
> close to MAXLONG).  Also, I think Paul's big patch may have
> addressed a few other issues that mine does not.

Yes, I agree.  It shouldn't be that hard to combine the ideas, but
I am worried that if we have one huge patch it will make it harder for
Aharon to evaluate the combination.

Aharon has been too busy to look into this, but if I were him I'd
rather see three separate patches:

(1) Fix the buffer overruns.
(2) Fix the rounding errors.
(3) Use %.0f to to handle %d for out-of-range integers.

Clearly the buffer overrun is #1 in importance.  The rounding errors
are bugs in the existing implementation (as they cause failure to
conform to POSIX), so they're #2.  (3) is a nice feature, but it's not
a bug fix so it's last.  Preferably all three patches would be
independent but I can understand why later patches might depend on
earlier.

As I understand it, Aharon has already implemented (1).  So perhaps he
should send us that fix first?  That might save us all some work.

Anyway, here are the problems I had with the patch you sent:

$ patch -p0 <$j/t
patching file node.c
Hunk #1 succeeded at 149 (offset 4 lines).
Hunk #3 succeeded at 200 (offset 4 lines).
patching file builtin.c
Hunk #1 succeeded at 593 (offset 18 lines).
Hunk #3 succeeded at 620 with fuzz 2 (offset 18 lines).
Hunk #5 FAILED at 966.
Hunk #6 FAILED at 1002.
Hunk #7 succeeded at 1085 (offset 19 lines).
Hunk #8 FAILED at 1108.
Hunk #9 succeeded at 1110 (offset 1 line).
Hunk #10 succeeded at 1257 (offset 16 lines).
3 out of 10 hunks FAILED -- saving rejects to file builtin.c.rej