Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 709 - netinet/ip_fw.h problem with long/u_32 members on the alpha
netinet/ip_fw.h problem with long/u_32 members on the alpha
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
Depends On:
  Show dependency treegraph
Reported: 1999-01-06 11:23 EST by Cristian Gafton
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-03-18 16:07:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Cristian Gafton 1999-01-06 11:23:47 EST
>       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
> 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
> 2.) Fix ipfwadm et al to not include <netinet/ip_fw.h> and
> <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
> architecture.  Thoughts?
Comment 1 Cristian Gafton 1999-03-18 16:07:59 EST
That header file is gone in the current beta (can not standardize
across platforms)

Note You need to log in before you can comment on or make changes to this bug.