The following reply was made to PR bin/29226; it has been noted by GNATS.
From: Arto Selonen <arto@xxxxxxxxxxx>
Cc: Ben Harris <bjh21@xxxxxxxxxx>, Klaus Klein <kleink@xxxxxxx>
Subject: Re: bin/29226: /etc/daily pipes >32bit integers from netstat to awk,
which can't deal with them
Date: Fri, 4 Feb 2005 16:21:11 +0200 (EET)
On Fri, 4 Feb 2005, Ben Harris wrote:
> From: Ben Harris <bjh21@xxxxxxxxxx>
> To: gnats-bugs@xxxxxxxxxx
> Cc: Klaus Klein <kleink@xxxxxxx>
> Subject: Re: bin/29226: /etc/daily pipes >32bit integers from netstat to
> awk, which can't deal with them
> Date: Fri, 04 Feb 2005 14:02:40 +0000
> In article <20050204135301.5E08463B400@xxxxxxxxxxxxxxx> you write:
> > I wouldn't mind awk(1) using intmax_t internally; however, there is
> > a showstopper in IEEE Std 1003.1-2001 section 1.7.2:
> > "Integer variables and constants, including the values of
> > operands and option-arguments, used by the standard
> > utilities [...] shall be implemented as equivalent to
> > the ISO C standard _signed long_ data type [...]"
> I think you're missing the fact that overflow behaviour of signed integer
> types in C is undefined, so the application can do anything it wants in case
> of overflow, including magically continuing to return arithmetically correct
> results. XRAT explicitly mentions that this was intended:
I forgot to mention that one could also handle over 8 digit long
numbers as strings (at least for the /etc/daily case, as it does not do
any arithmetic, but simply selects some fields and formats them nicely).
In the long run awk's 32bit limit probably needs to be dealt with,
one way or another.
#######======------ http://www.selonen.org/arto/ --------========########
Everstinkuja 5 B 35 Don't mind doing it.
FIN-02600 Espoo arto@xxxxxxxxxxx Don't mind not doing it.
Finland tel +358 50 560 4826 Don't know anything about it.