On 26 Apr 2024, at 15:01, Warner Losh wrote:
> This has to be a FAQ
>
> I'm porting a program from Linux, I often see an error like:
> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in 'struct
> in6_addr'
> 95 | ipv6->sin6_addr.s6_addr32[3] = 0;
> | ~~~~~~~~~~~~~~~ ^
> but yet, we kinda define them, but only for the kernel and boot loader:
> /*
> * IPv6 address
> */
> struct in6_addr {
> union {
> uint8_t __u6_addr8[16];
> uint16_t __u6_addr16[8];
> uint32_t __u6_addr32[4];
> } __u6_addr; /* 128-bit IP6 address */
> };
>
> #define s6_addr __u6_addr.__u6_addr8
> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */
> #define s6_addr8 __u6_addr.__u6_addr8
> #define s6_addr16 __u6_addr.__u6_addr16
> #define s6_addr32 __u6_addr.__u6_addr32
> #endif
>
> I'm wondering if anybody why it's like that? git blame suggests we imported
> that from kame, with
> only tweaks by people that are now deceased*.*
>
> Why not just expose them?
Looks like only s6_addr is specified in the RFCs (2553 and 3493). Oddly,
though, the RFCs give an example implementation using that union with
different element names (like _S6_u8), and show the one #define.
Similarly, POSIX specifies only s6_addr, but it allows other members
of the structure, so I don't see a problem with exposing them all even
in a POSIX environment.
I would have no objection to exposing all four definitions, especially
if Linux apps use them.
Mike
