In your previous mail you wrote:
> => I disagree, I'd like to be able to defined struct in6_addr as a pair
> of 64 bit integers one day (:-)!
I don't understand the point. The two 64 bit fields will be forced onto
their natural boundaries. This might lead to the compiler adding padding
between the ip6mtu_mtu and ip6mtu_dst but so what.
=> not so what, I prefer to have a layout which gives the same padding
with 4*32 and 2*64 bit definitions!
This structure doesn't go on the wire so padding that is added by
the compiler is not relevent.
=> with a right order 4*32 and 2*64 are binary compatible and you can
get this nice property for free.
[EMAIL PROTECTED]
PS: I've tried one day the 2*64 definition on a Sparc (ie. with 64 bit
alignment). It didn't work because of some details, for instance the
route structure (pointer + sockaddr) or IPv6 over ATM (32 bit difference
in alignment between unicast and multicast). I can't see a good reason
to add a new source of problems...
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
