The following reply was made to PR bin/29226; it has been noted by GNATS.

From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc: Ben Harris <bjh21@netbsd.org>, Klaus Klein <kleink@mibh.de>
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)

 Hi!
 
 On Fri, 4 Feb 2005, Ben Harris wrote:
 
 > From: Ben Harris <bjh21@netbsd.org>
 > To: gnats-bugs@netbsd.org
 > Cc: Klaus Klein <kleink@mibh.de>
 > 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@narn.netbsd.org> 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.
 
 
 Artsi
 -- 
 #######======------  http://www.selonen.org/arto/  --------========########
 Everstinkuja 5 B 35                               Don't mind doing it.
 FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
 Finland              tel +358 50 560 4826     Don't know anything about it.