eabjPLPQ+xW3sHvXJUUMajTw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=a8GsV5/NHRpYFhhDfAJ5VKyFu45FXxSoLLVGZqL53YY3MZce/gBKyPGMpuz39PjbC EKtks9VxJDeQ97Yk5PFE/H0yZAWeOhNFS+g96g7ar8jXVLSC2Ihi9wJUsGwUQZZpZa 1YtxroYghBD2Vn6VKcfAobxfk6unMoEE7/wz/9jDrIO6y63Z2oO4eMxDGM0p5fODIy RTqsifSzY5Z9JdsjsEJUmhSUlTxvOjWGq0Z+ikNfK4LD5qkMqM5Ra7V4StBKVo/wUJ 40LRzM5iC2bAyGbO1v7ro0I0DICTMiEo6MpH+jGkBpW7j66/nBcX8TUIWX+dkRipcn hN9v84N+nvHSg== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id iKxoM9QoLGbCSgEAs/W3XQ (envelope-from ); Fri, 26 Apr 2024 17:21:08 -0500 From: Mike Karels To: Warner Losh Cc: FreeBSD Net Subject: Re: Question about netinet6/in6.h Date: Fri, 26 Apr 2024 17:21:08 -0500 X-Mailer: MailMate (1.14r6028) Message-ID: In-Reply-To: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> References: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; R_DKIM_ALLOW(-0.20)[karels.net:s=mail2]; R_SPF_ALLOW(-0.20)[+ip4:3.19.118.201]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[mike]; DMARC_NA(0.00)[karels.net]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[karels.net:+] X-Rspamd-Queue-Id: 4VR6d31YmYz4NKF On 26 Apr 2024, at 15:49, Mike Karels wrote: > 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. I put the change, along with an explanatory comment, in https://reviews.freebsd.org/D44979. Comments welcome. Mike