>Obviously, they're talking about a general 'ALIGN' macro, which may or
>may not be the same as our specific alignment function.  our specific
>alignment function.
>
>Note that it says "next even multiple of whatever alignment is
>required."
>
>This is different than the alignment provided by our ALIGN macro and
>ALIGNBYTES value.  They align to the maximum possible necessary
>alignment, not the actual alignment needed.
>
>I'm aware of the old control msg needs for alignment: 4 bytes.  (they
>were all 4-byte ints, which in our worst case need to be 4-byte
>aligned.)
>
>As far as I can tell, none of the structures in RFC 2292 will have
>alignment needs > 4 bytes (since at most, they seem to use 4-byte
>fields), unless they're being used on architectures which happen to
>require 8 byte structure alignment (of which there are none that i'm
>aware; some normal ABIs for archs we support require 4-byte alignment
>for structs -- e.g. arm, which we've broken -- but none require 8 that
>i'm aware of).
>
>I may be missing something here, but ...
>For new ports, going forward, using 'ALIGNBYTES' might be a good thing
>to do, but at this point, i'm not sure why changing the existing
>definition from 3 -> ALIGNBYTES is necessary at all!

	I saw couple of align faults on netbsd/alpha, I may need to
	double-check if it was from cmsg, or from SIOCGIFCONF.

	I'll back out the changes I made soon, until the issue gets resolved.
	(hope this to be solved before 1.5 branching...)

itojun