From nobody Sat Apr 27 03:41:09 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 4VRFkX5yTJz5HNxW for ; Sat, 27 Apr 2024 03:41:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 4VRFkX4BtVz4xFK for ; Sat, 27 Apr 2024 03:41:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-5194cebd6caso3160963e87.0 for ; Fri, 26 Apr 2024 20:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1714189281; x=1714794081; 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=5DDExenNDBuaf3HKgQL9K2hH0NwCrzu/dyoTcGztwq8=; b=S59bXXNxprMFgj4sc5+yb6NNtAmNBoQr5TWMk4MzIsmrIaH2k90q+qRaTbTBiqqdLh q4AEG4nrlwinkkt0AYvIXeM0WNkxh0jS3ub5abLwJQLhjk62o3nGkcfM4BmwEsbV3D3/ Ie7n2girW49p7w0fA9o55jYLcdHVrd/7FdIkuDqucRg8xThejnAyPYXkRrTxVgb/x0K6 s8xEkYjpMZhc67OtRCWzmOFOHPqDlEvKakAHjRa2ekmx/AYc2heCvBQVCvSmqiT+ETBZ HaLFAmrymWl8qLHCNfiVFvJzhV00OTD2Wb477Q1pCnxsSobD8tJY1iBaieMg8uu9EZoy tX2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714189281; x=1714794081; 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=5DDExenNDBuaf3HKgQL9K2hH0NwCrzu/dyoTcGztwq8=; b=fcfbTupmHnQZbCYTQOgxukMUPS7N91tcgBtVmdI3duFCBu79NYmwR/73kwEakCMSXs bZ3hc1YwM4SKLRpX01FtQa6FplvugQAk4c/5APNSIBX5cmWRssGn7/lOlfpp7Bmrnl1H 3LRwhdmqmfIOwGewv1O896MoZn2Vi6TZpoVGb9ymcCEdML1Wjc3FHU12R/LoTHCSIHQt Fa4izGzkzSTSyIYXKlRg3HnxcoFThmr38ODP6bDVn6dsiUHuccH4Pd1e6xruftsRZtUI mmCsP0J7nXaw9KES33TAanFUHV/MKuHyYpYevquJEJtnI2sGmbFDUZchg0+Owp9uZlcP Ex9Q== X-Forwarded-Encrypted: i=1; AJvYcCUrsGGz8DoKmG4idmDEqkPw5++RFizGAhFwygOXESLbiLDMiYRxzMBcropUGJPwU/LeDRcPpEXxYXR4KhmkhtrwhPDfEshlNw== X-Gm-Message-State: AOJu0YzIPrX7KdJ3KwQJdQ9EEorWVPth44ASpzgvOGyuXdjtS+B+N7fu xi2eSWXse9Zd5xcjz0+uHBP9wiE/Qrhw9AN/6EmNljCwfLVArEGvfXD5fE6nzMm8pJON46ngo9T 95B1GppW1KXA5Qj10R13jJPfQjKuv5Kci8+wnx71PFKCRAgau X-Google-Smtp-Source: AGHT+IGkTZaPaBuH47AgnNUcYWKd1CtwQmFVseug4jxUCxg858lHTacP74c+rVY5dEk6EyM8uSXZGz3BvbSGMuLrBrI= X-Received: by 2002:a19:e017:0:b0:51b:e46c:19fc with SMTP id x23-20020a19e017000000b0051be46c19fcmr2651312lfg.58.1714189281459; Fri, 26 Apr 2024 20:41:21 -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> <4AF50212-9141-44FF-937F-A06AF8B15121@karels.net> <54E63C68-2713-4247-A57C-D3AA9C571327@iitbombay.org> In-Reply-To: <54E63C68-2713-4247-A57C-D3AA9C571327@iitbombay.org> From: Warner Losh Date: Fri, 26 Apr 2024 21:41:09 -0600 Message-ID: Subject: Re: Question about netinet6/in6.h To: Bakul Shah Cc: Mike Karels , FreeBSD Net Content-Type: multipart/alternative; boundary="00000000000033267b06170bcb31" 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: 4VRFkX4BtVz4xFK --00000000000033267b06170bcb31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2024, 9:33=E2=80=AFPM Bakul Shah wrot= e: > > > > On Apr 26, 2024, at 5:02=E2=80=AFPM, Mike Karels wrot= e: > > > > On 26 Apr 2024, at 18:06, Warner Losh wrote: > > > >> 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). > Oddly, > >>>> though, the RFCs give an example implementation using that union wit= h > >>>> 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 ev= en > >>>> in a POSIX environment. > >>>> > >>>> I would have no objection to exposing all four definitions, especial= ly > >>>> 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 hav= e > 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 o= f > >> indirection). > > > > I thought briefly about __BSD_VISIBLE, but wasn't sure it was necessary= . > > Let me know what you find out. I think it should work either way; in.h > > includes cdefs.h, so it's guaranteed to have been included. > > If the -ms-extensions option is used with gcc or clang, this ugliness can > go away as you can have nested anonymous unions or -structs and their > fields > can be referenced as if they're directly in the parent struct/union. > > [IIRC this was present in Plan9 C from very early on. Also in C11 or late= r] True. In fact c11 and newer doesn't need anything on the command line here. If it were only in the kernel then I'd chamge it like thay while I was here... but lots of code in ports will specify c99 + POSIX 2001 and to compile there your only hope is this construct.... Warner --00000000000033267b06170bcb31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 26, 2024, 9:33=E2=80=AFPM Bakul Shah <<= a href=3D"mailto:bakul@iitbombay.org">bakul@iitbombay.org> wrote:


> On Apr 26, 2024, at 5:02=E2=80=AFPM, Mike Karels <mike@karels.net&= gt; wrote:
>
> On 26 Apr 2024, at 18:06, Warner Losh wrote:
>
>> On Fri, Apr 26, 2024 at 4:21=E2=80=AFPM Mike Karels <mike@karels.n= et> 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 e= rror like:
>>>>> ./test/mock-ifaddrs.c:95:19: error: no member named &#= 39;s6_addr32' in
>>> 'struct
>>>>> in6_addr'
>>>>>=C2=A0 =C2=A095 |=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~~~~~~~~~~~~~~~ ^
>>>>> but yet, we kinda define them, but only for the kernel= and boot loader:
>>>>> /*
>>>>> * IPv6 address
>>>>> */
>>>>> struct in6_addr {
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 union {
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= uint8_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= uint16_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= uint32_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 __u6_addr32[4];
>>>>>=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 addr= ess */
>>>>> };
>>>>>
>>>>> #define s6_addr=C2=A0 =C2=A0__u6_addr.__u6_addr8
>>>>> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX no= nstandard */
>>>>> #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? g= it 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).=C2=A0 Oddly,
>>>> though, the RFCs give an example implementation using that= union with
>>>> different element names (like _S6_u8), and show the one #d= efine.
>>>> Similarly, POSIX specifies only s6_addr, but it allows oth= er members
>>>> of the structure, so I don't see a problem with exposi= ng 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, but I like yours better...= though
>> maybe
>> we should just make it visible when __BSD_VISIBLE is true.... I= 9;ll have to
>> look
>> closely at what Linux does here... I think they have it always vis= ible, or
>> at least
>> musl does that (glibc is harder to track down due to the many laye= rs of
>> indirection).
>
> I thought briefly about __BSD_VISIBLE, but wasn't sure it was nece= ssary.
> Let me know what you find out.=C2=A0 I think it should work either way= ; in.h
> includes cdefs.h, so it's guaranteed to have been included.

If the -ms-extensions option is used with gcc or clang, this ugliness can go away as you can have nested anonymous unions or -structs and their field= s
can be referenced as if they're directly in the parent struct/union.
[IIRC this was present in Plan9 C from very early on. Also in C11 or later]=

True= . In fact c11 and newer doesn't need anything on the command line here.= If it were only in the kernel then I'd chamge it like thay while I was= here... but lots of code in ports will specify c99 + POSIX 2001 and to com= pile there your only hope is this construct....

=
Warner=C2=A0
--00000000000033267b06170bcb31--