From nobody Sat Apr 27 04:02:34 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 4VRGCD4rJzz5HRR2 for ; Sat, 27 Apr 2024 04:02:48 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 4VRGCD2ljPz51bg for ; Sat, 27 Apr 2024 04:02:48 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-2a519ac18b3so2171946a91.2 for ; Fri, 26 Apr 2024 21:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1714190566; x=1714795366; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QC78cVQehSmRCqqBIDPPJJbcO64W/t789ZC7YOT2+pE=; b=gh58B3baXekK5lLCwrke0by8H9tDk95jOdwmdQM0/tUu6s+CjzowG2/MWD2BU9r7ft iYotlD1cr8q2Avkp8F+JB5xYYIBt1G4odi6lAW4ZSJsi+XIU2qCXRIZtqNhBRVmxNTFy djd7EN3p091GFVmI8kGsJmWTymhQ7cSAimmMrhfcj3MhtKWJz0oaVODGka85y+VP8w2+ 6MvRMY3QqC7GppoA4Bc22bN8B9vDabstjkXBctv4wNfXt/T51opqQklAkVuI7RFy1/35 V8JOcOCyKCy+T0FBk1FTwLsLF8oVFBj3JA/8k3JDSbtFj/L4AHKI2oS/YX2w4/Vq36L3 MWPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714190566; x=1714795366; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QC78cVQehSmRCqqBIDPPJJbcO64W/t789ZC7YOT2+pE=; b=Hd6NJYyh7hS7ujhZoPLwgrYXr4LkIlz7Qps6TZ7GgPZjmraRA0e8bDDGdLDbKwoEz8 RY3kaOt7inMejwTLjAapRC3Sn7J8TUlc/u+qxqJN7CXevlcgQojyPd1DeEQ+tBa3qxGQ hjzEjK0q5t6ADcLa/KFxb2J45o1RU6wGW6ejTIMREKYU8+lC0ou0aOe2DDdivT2nJmmB VFsy4rEMFiUagbeeJbp4RiUDOwKJQIwpzNW9+hs0iNe+dQwMAPVerhJZpPeX3uHWs70Q hXfseav1i58CXl/d+qz4w3FDMhg3KFkYFhyzWhwk4pYL/5jkNwdEP1OZu0n8EOJP/bh2 ePKQ== X-Forwarded-Encrypted: i=1; AJvYcCUJofKH8vJgp2/TwsSxfiRKdunFT4a7EiXy8d8yctpGZY8Rqx/gKDIKyZiR9KOoGUzZJdQ6z2QDmYdgLumBIDRxsNV2c/KwbA== X-Gm-Message-State: AOJu0YwcPwtSjJadt0HgjJS34XNIn+etiTMZjwD5xm5pakEt0w8zUEge sZUG0DePePQEWjBpSpMgZ5mpDGHYOn60FIOUsaTd5uRNXyoQfzP1GqHOuPdlwzK2Nmcek/yWEH8 = X-Google-Smtp-Source: AGHT+IFKM3llvtaXGvtRgr6/5hL+BQCOYeaSCAEVEpM3N8GF+f2LXLO+i53Y2ElkmffezKNtPbTlTw== X-Received: by 2002:a17:90b:310f:b0:29b:c2b3:2712 with SMTP id gc15-20020a17090b310f00b0029bc2b32712mr4721144pjb.26.1714190566454; Fri, 26 Apr 2024 21:02:46 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id y10-20020a17090ad70a00b002a63e966fd7sm15256858pju.47.2024.04.26.21.02.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2024 21:02:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Question about netinet6/in6.h From: Bakul Shah In-Reply-To: Date: Fri, 26 Apr 2024 21:02:34 -0700 Cc: Mike Karels , FreeBSD Net Content-Transfer-Encoding: quoted-printable Message-Id: References: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> <4AF50212-9141-44FF-937F-A06AF8B15121@karels.net> <54E63C68-2713-4247-A57C-D3AA9C571327@iitbombay.org> To: Warner Losh X-Mailer: Apple Mail (2.3774.500.171.1.1) 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:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4VRGCD2ljPz51bg On Apr 26, 2024, at 8:41=E2=80=AFPM, Warner Losh wrote: >=20 >=20 >=20 > On Fri, Apr 26, 2024, 9:33=E2=80=AFPM Bakul Shah = wrote: >=20 >=20 > > On Apr 26, 2024, at 5:02=E2=80=AFPM, Mike Karels = wrote: > >=20 > > On 26 Apr 2024, at 18:06, Warner Losh wrote: > >=20 > >> On Fri, Apr 26, 2024 at 4:21=E2=80=AFPM Mike Karels = wrote: > >>=20 > >>> On 26 Apr 2024, at 15:49, Mike Karels wrote: > >>>=20 > >>>> On 26 Apr 2024, at 15:01, Warner Losh wrote: > >>>>=20 > >>>>> This has to be a FAQ > >>>>>=20 > >>>>> 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 */ > >>>>> }; > >>>>>=20 > >>>>> #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 > >>>>>=20 > >>>>> 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*.* > >>>>>=20 > >>>>> Why not just expose them? > >>>>=20 > >>>> 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. > >>>>=20 > >>>> I would have no objection to exposing all four definitions, = especially > >>>> if Linux apps use them. > >>>=20 > >>> I put the change, along with an explanatory comment, in > >>> https://reviews.freebsd.org/D44979. Comments welcome. > >>>=20 > >>=20 > >> 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). > >=20 > > 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. >=20 > 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. >=20 > [IIRC this was present in Plan9 C from very early on. Also in C11 or = later] >=20 > 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.... Such defines were typically within #if defined(KERNEL) .. #endif so non-kld ports shouldn't be referring to them, right?!