Mistakes in glibc-2.0.7 includes

["B. James Phillippe" <bryan terran org>]

Hello,

	I posted this information quite a while back but never got any
response.  I'd like to know what other folks think about this, if anyone
can please comment.

The problem is that some files in the glibc includes specify fixed-size
variables (u_int32_t, u_int16_t, etc) in places where natural-size
variables are required.  In particular, <netinet/ip_fw.h> specifies struct
ip_fw as such:

struct ip_fw {
  ...
  u_int16_t fw_nsp, fw_ndp;    /* N'of src ports and # of dst ports */
  ...
  u_int32_t fw_pcnt, fw_bcnt;    /* Packet and byte counters */
  ...
};

fw_nsp and fw_ndp show a proper usage of fixed-size variables, afterall, a
port number is specified to be 16 bits.  However, the variables fw_pcnt and
fw_bcnt are an explicit 32 bits.  The problem is subtle..  These same
values in the Linux kernel are specified as "unsigned long".  On x86,
u_int32_t and unsigned long coincidentally happen to be the same size, and
the bug is masked.  However, on Alpha (and presumably UltraSparc) unsigned
long is 64 bits.  Now the bug is apparent, because when networking tools
use the include from the glibc headers, the struct ip_fw has the wrong
size.  This can cause syscalls such as setsockopt() to fail -EINVAL.

The suggestion is to make variables which do not clearly require an
explicit size to use a natural size.  In the case I point out here, there
is no logical reason I can see to force a counter variable to a specific
number of bits.  Why limit architectures that are capable of better?

FWIW, this little bugger is the cause of the "ifpwadm does not work" on
RedHat-5.1 and several unaligned accesses in various other networking tools
(several in net-tools).  I suspect a similar problem with tcpdump also, but
have not yet investigated further.

thanks,
-bp
--
B. James Phillippe <bryan@terran.org>
Linux Software Engineer, WGTI.
http://earth.terran.org/~bryan