Subject: RE: ipf counting and rrdtool
To: None <netbsd-users@NetBSD.ORG>
From: Greg A. Woods <>
List: netbsd-users
Date: 07/14/2001 02:43:00
[ On , July 13, 2001 at 21:27:53 (-0500), Bruce Anderson wrote: ]
> Subject: RE: ipf counting and rrdtool
> On Fri, Jul 13, 2001 2:31 AM, Greg A. Woods <> wrote:
> >
> >That's the same as nawk's too....
> >
> >	$ nawk 'END {print OFMT}' < /dev/null
> >	%.6g
> >
> >Oddly nothing I can find in gawk's manual talks about this weird
> >side-effect on "print" of changing OFMT....
> >
>    "The printf Statement
>        The AWK versions of the  printf  statement  and  sprintf()
>        function (see below) accept the following conversion spec-
>        ification formats:"

That's "printf", not "print".

       "OFMT        The  output  format  for  numbers,  "%.6g", by

But I'm beginning to learn after all these years that some awk's treate
OFMT as the default format for printing numbers with "print".  I don't
know why but I didn't make the connection before.

The One True Awk (nawk) works very much the same as gawk for printf()
and sprintf() (and CONVFMT).

                                             The printf statement
       formats its expression list according to the  format  (see

       sprintf(fmt, expr, ... )
              the  string  resulting  from  formatting  expr  ...
              according to the printf(3) format fmt

Mawk's manual is a bit more explicit about "print" though:

              print expr1, expr2, ..., exprn
                     writes  expr1 OFS expr2 OFS ... exprn ORS to
                     standard output.   Numeric  expressions  are
                     converted to string with OFMT.

It turns out that nawk never makes use of OFMT (despite documenting it
in almost exactly the same way as gawk and mawk).

These differences though are very disturbing!

$ awk 'BEGIN {OFMT="0x%x"} END {print 4294967296 + 4294967296}' < /dev/null
$ mawk 'BEGIN {OFMT="0x%x"} END {print 4294967296 + 4294967296}' < /dev/null
$ gawk 'BEGIN {OFMT="0x%x"} END {print 4294967296 + 4294967296}' < /dev/null

I'm still using gawk-3.0.4 (and mawk 1.3.3) though -- perhaps gawk-3.1.0
works a bit better in this respect.  I wonder when pkgsrc/lang/gawk will
get updated....  :-)

It would be nice to know what numerical handling limits are present in
each version, especially for an accounting problem like this where
"large" integers are likely to be encountered.  It looks as though nawk
and gawk are both using floats internally while mawk uses host "int".

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>     <>
Planix, Inc. <>;   Secrets of the Weird <>