>       I don't understand what you are saying, at all.
>       ip6mtu_dst will be aligned to the alignment whatever necessary for us,
>       depending on how your compiler aligns it.  sockaddr_in6 includes
>       struct in6_addr (sin6_addr), and if you declare in6_addr like:
>               struct in6_addr {
>                       union {
>                               uint8_t foo8[16];
>                               uint16_t foo16[8];
>                               uint32_t foo32[4];
>                               uint64_t foo32[2];
>                       } foo;
>               };
>       ip6mtu_dst.sin6_addr should be aligned to 64bit boundary.
> 
> >     ip6mtu_dst will be aligned to whatever look natural to the machine
> >     based on sockaddr_in6 declaration.

You are correct that the compiler will take care of this by inserting
any necessary padding in the data structure.
I think there were some concerns about data structure size when sockaddr_in6
was defined which is why the flowid was placed before the address. This
ensured that even if in6_addr is 64 bit aligned the compiler wouldn't
need to insert a pad of 32 bits.

I don't know if there is a concern of wasting space in the ip6_mtuinfo
structure by having compiler inserted padding. This can be avoided 
by placing the mtu after the sockaddr_in6.

  Erik

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to