bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gawk number to string bug


From: Andrew J. Schorr
Subject: Re: gawk number to string bug
Date: Mon, 26 Dec 2005 12:45:24 -0500
User-agent: Mutt/1.4.1i

On Sat, Dec 24, 2005 at 09:58:58PM +0200, Aharon Robbins wrote:
> The %.40d bug is indeed a problem that needs solving, no matter what.
> 
> In terms of negative zero, I get slightly different results from other
> awks, but I'm inclined that it should print as positive zero. Those who
> shudder in horror about lack of precision, etc. etc should simply find
> another language in which to do their high precision work...
> 
> The rounding issue needs to be solved.  Andrew, does your latest patch
> fix that?  If not, can you resend a patch that handles it as well for
> me to evaluate?

I am attaching a patch that seems to solve the problem with "-0". 
I had to add an explicit test for this case; perhaps someone else
can see a more elegant way.

Anyway, I think the attached patch addresses the buffer overflow bug
as well as the 2 issues raised by David.  However, 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. 

And I added a patch that Paul will not like to address problems with
non-base-10 formatting (e.g. "%o").

So, for example, on 64-bit opteron linux, with standard gawk 3.1.4,
I get:

$ gawk --lint 'BEGIN { x=2^60; for(i=60;i<=65;i++) { printf "2^%d= %s %d %g 
%o\n",i,x,x,x,x; x*=2}}' 
2^60= 1152921504606846976 1152921504606846976 1.15292e+18 100000000000000000000
2^61= 2305843009213693952 2305843009213693952 2.30584e+18 200000000000000000000
2^62= 4611686018427387904 4611686018427387904 4.61169e+18 400000000000000000000
2^63= -9223372036854775808 9223372036854775808 9.22337e+18 
1000000000000000000000
2^64= 1.84467e+19 0 1.84467e+19 0
gawk: warning: [s]printf: value 3.68935e+19 is out of range for `%d' format
gawk: warning: [s]printf: value 3.68935e+19 is out of range for `%o' format
2^65= 3.68935e+19 3.68935e+19 3.68935e+19 3.68935e+19

But with my patched version, I get:

$ gawk --lint 'BEGIN { x=2^60; for(i=60;i<=65;i++) { printf "2^%d= %s %d %g 
%o\n",i,x,x,x,x; x*=2}}' 
2^60= 1152921504606846976 1152921504606846976 1.15292e+18 100000000000000000000
2^61= 2305843009213693952 2305843009213693952 2.30584e+18 200000000000000000000
2^62= 4611686018427387904 4611686018427387904 4.61169e+18 400000000000000000000
2^63= 9.22337e+18 9223372036854775808 9.22337e+18 1000000000000000000000
gawk: warning: [s]printf: value 1.84467e+19 is out of range for `%o' format
2^64= 1.84467e+19 18446744073709551616 1.84467e+19 1.84467e+19
gawk: warning: [s]printf: value 3.68935e+19 is out of range for `%o' format
2^65= 3.68935e+19 36893488147419103232 3.68935e+19 3.68935e+19

My principal question about the format_tree patch is whether PREPEND is too big
to be a macro (i.e. should there be a little function to do this instead of a
macro).

Also, some thought probably needs to be given to how NaN values are treated
with this patch.

Regards,
Andy

Attachment: int_format.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]