Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 709 - netinet/ip_fw.h problem with long/u_32 members on the alpha
Summary: netinet/ip_fw.h problem with long/u_32 members on the alpha
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 5.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-01-06 16:23 UTC by Cristian Gafton
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-03-18 21:07:30 UTC


Attachments (Terms of Use)

Description Cristian Gafton 1999-01-06 16:23:47 UTC
>       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 21:07:59 UTC
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.