Re: Question about netinet6/in6.h

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