From nobody Fri Apr 26 23:06:31 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VR7dg3qc3z5JQZh for ; Fri, 26 Apr 2024 23:06:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VR7dg27swz4R5d for ; Fri, 26 Apr 2024 23:06:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-5176f217b7bso4588845e87.0 for ; Fri, 26 Apr 2024 16:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1714172803; x=1714777603; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=c3dy+ceOxcsoKDfUFBpMSBZDiKRrtn2W2zv2bfcVlfU=; b=J1Y9DvAdGTYTDxtwnfmIfo8qYu5UydUIPophSq4KvLYPzWaxpA560VpuQDHqUH+UEy fJ6a5SEg6ey7vvdryfPBiJNtFmATI/oSHdSUERJhQnDrviIwGSHiSxmi0qzsgNADAZFg 3J08oOs5ma1KG545TFWxQE3TWNDUt4KsMEOhqz4F4WXwHLlndfV3aKQUNtKhDj6V/dCU VAInqWwkFBiZybF2Vp684OF4SXxquV19v0sO42UAWbBDqzndDgbdNTsvoR5VD0dVbNsv cPsltsLcIBNzh9HhVsVjgNNot4KpxmdP/8SPIcfGIRlkPSgRUN0bMQPY+2aN52uG6Nx5 4xwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714172803; x=1714777603; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c3dy+ceOxcsoKDfUFBpMSBZDiKRrtn2W2zv2bfcVlfU=; b=Rr/C29iKgsg6AKO6ctHQap4RiW9sGQS8M6Gf7aJYZmAvDgdBRYllDurqYUGQwB4LBn woOTkE7uWP3tZSyCUTSlF7L6CyyO6zEYJV/4vZwFKe2nMsUiRivZoZdMbFlIFoDzZfKb TESfljWmOy5NXmyS4q0pyvRUB4u2JGoE53OgHyHxXWLgCafzOyZCT9ycgHKcIGOczA1S L+QgCZwEvNVD/+d8vrrwLe9q6eY87lrfDPMThtdKrO7DVqGx6IyCfAd4x2gI8wV8LTVt 9uucQVWXXgllPgAecLClYgx6rVzAwFhdnEAGnmbxDopYDJRGWqSeaqoRvFfIN+jWwc6S NuBw== X-Gm-Message-State: AOJu0YwKt8cdPVa7VObl4y0i5AFklBVn//7osut5g2+AGEOouBH5+wI5 TlvSjID6rj2Vajw5ihNS2O030mix0/xHy9s9ImEEusslGBXHpF8FzOayRNUbMjQCGUHpyqPsSmE zWLdDPt0ZThuSskqjhnzbyioAQsImwhJDh7vD+Q== X-Google-Smtp-Source: AGHT+IF4cG2iWzY6JW13Fymw8xJyrHP8rpHduJ0gpEcKhbxOYKbqkkxTJP71t86pfcRDlzRl65rLmgFmsyg61NK5pWA= X-Received: by 2002:a19:ca54:0:b0:516:d09b:cbe4 with SMTP id h20-20020a19ca54000000b00516d09bcbe4mr3287326lfj.53.1714172802760; Fri, 26 Apr 2024 16:06:42 -0700 (PDT) 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 References: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> In-Reply-To: From: Warner Losh Date: Fri, 26 Apr 2024 17:06:31 -0600 Message-ID: Subject: Re: Question about netinet6/in6.h To: Mike Karels Cc: FreeBSD Net Content-Type: multipart/alternative; boundary="000000000000fe240c061707f464" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VR7dg27swz4R5d --000000000000fe240c061707f464 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2024 at 4:21=E2=80=AFPM Mike Karels wrote= : > 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] =3D 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). Oddl= y, > > 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. > Thanks! I was testing a similar change, but I like yours better... though maybe we should just make it visible when __BSD_VISIBLE is true.... I'll have to look closely at what Linux does here... I think they have it always visible, or at least musl does that (glibc is harder to track down due to the many layers of indirection). Warner --000000000000fe240c061707f464 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 26, 2024 at 4:21=E2=80=AF= PM Mike Karels <mike@karels.net&g= t; wrote:
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'
>>=C2=A0 =C2=A0 95 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0ipv6->sin6_addr.s6_addr32[3] =3D 0;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0~~~~~~~~~~~~~~~ ^
>> but yet, we kinda define them, but only for the kernel and boot lo= ader:
>> /*
>>=C2=A0 * IPv6 address
>>=C2=A0 */
>> struct in6_addr {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0union {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint8= _t=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__u6_addr8[16];
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint1= 6_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 __u6_addr16[8];
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint3= 2_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 __u6_addr32[4];
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} __u6_addr;=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 128-bit IP6 address */<= br> >> };
>>
>> #define s6_addr=C2=A0 =C2=A0__u6_addr.__u6_addr8
>> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */=
>> #define s6_addr8=C2=A0 __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 sug= gests 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).=C2= =A0 Oddly,
> though, the RFCs give an example implementation using that union with<= br> > 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.=C2=A0 Comments welcome.

Thanks! I was testing a similar change, b= ut I like yours better... though maybe
we should just make it vis= ible when __BSD_VISIBLE is true.... I'll have to look
closely= at what Linux does here... I think they have it always visible, or at leas= t
musl does that (glibc is harder to track down due to the many l= ayers of indirection).

Warner
--000000000000fe240c061707f464--