>       Under linux-2.0.35, <linux/ip_fw.h> defines struct
ip_fw to have
> members fw_pcnt and fw_bcnt as unsigned long.  This sounds
reasonable.
> Under glibc-2.0.7, <netinet/ip_fw.h> defines that same
struct ip_fw to have
> members fw_pcnt and fw_bcnt as u_int32_t.  At first glance
that might sound
> reasonable too.  But it is not.  To my Alpha, long and
u_int32_t are two
> different animals.  ipfwadm (stock from RedHat-5.1/AXP) is
unusable for
> this reason.  To fix, I had to redefine those pesky
u_int32_t's as longs
> and recompile ipfwadm.  netstat appears to have this same
problem.  Surely
> there is something amiss here.  What exactly is the fix?
>
> 1.) Fix glibc so it doesn't use specified-sized variables
where they can
> hurt (for instance, u_int8_t is always safe, and u_int32_t
is always safe
> for something like an ipv4 addr, but not necessarily other
things).
>
> 2.) Fix ipfwadm et al to not include <netinet/ip_fw.h> and
preference
> <linux/ip_fw.h> instead.  But wouldn't this contradict one
of the purposes
> of glibc, however?
>
> In any case, what is the point of glibc hard-coding byte
and packet
> counters to a measly 32 bits anyway?  ;)  It seems like it
would better
> serve to let most variables match the natural size for the
underlying
> architecture.  Thoughts?