> From: itojun@iijlab.net
>
> 	As noted in PR#8179 and #8305, there's 64bit alignment issue in
> 	routing socket.  This has been invisible until IPv6 merge because
> 	all sockaddr_* structure are sized as multiple of 8 bytes.
> 	sockaddr_in6 comes as exception and raises alignment issue.
>
> 	From what I've looked, many of exisitng programs do like:
> 		rtm = (struct rt_msghdr *)next;
> 		sin = (struct sockaddr_in6 *)(rtm + 1);
> 		sdl = (struct sockaddr_dl *)(sin + 1);
> 	while sys/net/rtsock.c uses ALIGN().  I feel that sys/net/rtsock.c
> 	should avoid use of ALIGN() for compatibility with existing codebase,
> 	but I'm not 100% sure.
> 	Is there any standard document on this?  If not, I'll change
> 	sys/net/rtsock.c to generate packed structures (not ALIGN'ed) on
> 	routing socket reads.

Umm, wait a minute, sys/net/rtsock.c does NOT use ALIGN(). It uses
local macros to align to sizeof long.

It's probably best not to change the interface.

Furthermore, for some reason, I think ALIGN() does in fact align to > sizeof
long on some ports.

I would suggest:

	* edit route.4 to simply document the alignment to sizeof long

	* modify clients to adapt, possibly by exporting a new alignment
	  convenience macro in /usr/include

I agree with you, BTW, that a sort-of clean solution would be to generate
packed structures from rtsock.c. It's annoying that the kernel does this
sometimes (e.g., the widely used SIOCGIFCONF) but not others, but I'm afraid
it's too late to change it. (And anyway, those packed structures are a big
source of other bugs ... it's amazing how much cascaded lossage flows from
the variable length sockaddr feature.)

Note also that a really paranoid program might _still_ want to memcpy()
the structures to memory allocated by the compiler or malloc(3) before
addressing them, as there is no guarantee that sizeof long will be a
sufficient alignment for all time, although it might be. But I wasn't that
paranoid before I was targetted by the mind control rays from the black
helicopters. (HI TY!)

	ross.harvey@computer.org