You may want to ask this type of question at ipv6@ietf.org, but
anyway:
>>>>> On Tue, 1 Nov 2005 18:00:49 -0500 ,
>>>>> [EMAIL PROTECTED] said:
> In RFC 3493, it says:
> struct in6_addr {
> union {
> uint8_t _S6_u8[16];
> uint32_t _S6_u32[4];
> uint64_t _S6_u64[2];
> } _S6_un;
> Why is it not:
> struct in6_addr {
> union {
> uint8_t _S6_u8[16];
> uint16_t _S6_u16[8];
> uint32_t _S6_u32[4];
> uint64_t _S6_u64[2];
> } _S6_un;
> Adding the uint16_t breakdown seems like it would be useful, and cost
> nothing. Is there some non-obvious reason it was left out?
Note that the union definition in RFC3493 is an "example" of
"implementation details". My interpretation is that an individual
implementation can freely adopt the latter (or other) type of
definition. In fact, *BSDs' internal definition is as follows:
struct in6_addr {
union {
u_int8_t __u6_addr8[16];
u_int16_t __u6_addr16[8];
u_int32_t __u6_addr32[4];
} __u6_addr; /* 128-bit IP6 address */
};
(It's for FreeBSD, but I belive other BSDs also have __u6_addr16).
One important point is, however, that a portable applications should
not assume such internal details. So, for example, it should be
generally discouraged for an application to get access to the
__u6_addrXX members directly or to assume the internal data is aligned
at some particular boundary.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
---------------------------------------------------------------------
The IPv6 Users Mailing List
Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
