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
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
5.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 1999-03-18 16:07:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
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?
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.