> From: itojun@iijlab.net
>
> >> So, are there more LP64 fixes to do?  Can I help?  :)  Any suggestions?
> >Yes, though I'm not sure what. All of the IPv6 structs seem to have
> >explicit references to u_long, long, etc.. in them. They need to be
> >explicit sizes, like u_int32_t, etc..
> >Take care,
>
> 	Some of them are fixed by now.  Report from Jeff seems to be
> 	more about struct alignment with SIOCGIFCONF.


OK, I have some portability advice here, too.

SIOCGIFCONF returns an object that has no builtin support in C, but it's
called elsewhere a "packed array". This is because the sockaddr structure
has a (sometimes) variable length. Although IFNAMSIZ is fixed, the link-
level and other addresses inside the sockaddr elements in struct ifreq have
variable lengths and are sometimes the determining item for the size of
that struct in the returned (and packed) array.

The _only_ portable way to access an element from this list is to first
memcpy() the one you want to a struct that is allocated by the compiler or
malloc(3), i.e., one that is not packed. Presumably, this needs to be in
a union with a padded-out array to allow for the maximum size the application
wants to support, or allocated with malloc(3) for either the actual size,
a local fudge increment, or perhaps _SS_MAXSIZE.

Sadly, the natural tendency of C programmers seems to be to compute a
pointer into the packed array and use it directly. This violates C89 and
C9X, it causes various machine-dependent lossage modes, but, also sadly,
it works OK (if a bit more slowly) on x86.

Summary:
	I suspect the struct alignment lossage is not in the kernel or
	the ioctl, but is in the way userland is incorrectly attempting
	to directly address the returned packed array, which now doesn't
	have the coincidentally-aligned IFNAMSIZE-dominated elements any
	more.

ross.harvey@computer.org