From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id DE830385773C for ; Fri, 21 Apr 2023 15:00:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DE830385773C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-3f09b9ac51dso52862395e9.0 for ; Fri, 21 Apr 2023 08:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682089216; x=1684681216; h=in-reply-to:references:cc:to:from:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=fj7dIkdI9D0+VDal2P+Qc/VAElEhc94iq6EnBdAkk+4=; b=sAwVMwBDMres1uso1oB9+BlOf+GdYYguheHk7dZnYoxb35j6fvFhRzM8vcuS1bYngH KF/3OH3108/0kBFEq5z+IP9DETv1r8FpawScBw54KBJk60/A3gatCmtq6TKST2R03M+9 S1MCfOpGX3gHqslf7MAHhKSXQzYcsWe3sdCmLaITzeR+tVWT626Aba4bv79TjJGr0syE KujlS3NETazIqICbsSY9eu3VVhkqXDRSH1/IMEulsgqngeiW6IKYOV/z9bLWgYsHmYcS l0oi5wTRPLohsbeS/1hqROsHq+qlZxoYLl1aNwp6L40Xy1QP+t27RiWlnyeW2OuuQhum u2Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682089216; x=1684681216; h=in-reply-to:references:cc:to:from:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=fj7dIkdI9D0+VDal2P+Qc/VAElEhc94iq6EnBdAkk+4=; b=HtqoU41Z4D4ylQCVLK1Edx3Ugbns9sVif6M9ir9dXTDRvz2V2KCVOnGNQ5J9k+xB03 VVT9RR0ufdEBiBc7kWBa0dZjG42jueipZWrraY0BcWq286DOm3aHZZSbbk4uofoq0onh p5vkG4nlA+Ld2H4corAdh2Cxe+hrV17vxCLaokG48EONaIivvqfDvsenHt5zFjUHae7g XkSl2pHbwucPnclODEx0qvk3/1HVjO90aqYRdI7PyaLcbqEbKMcbSKwKC/QLTyjR4c0H bAea1121cqYhc2xVzMFT+mgK2+3Ze+eV07eSIGesYh1vBAQ0oJ0sbvq7Nie9stagALbp RvTQ== X-Gm-Message-State: AAQBX9dDXizv6/74/IbcrPTEKouOfpOVGItypA5EsFhrfZb9PZlrQG6o TnX1KF8fSUV9fCM6/SHeSjqRtn91U0E= X-Google-Smtp-Source: AKy350aY/1bZWVqtZDa2a1T8Fr0d3ZXgA8TxXX3OIii+pO/AZqz2YliQzm61S/p4uZbmVuu6SWJM6w== X-Received: by 2002:a5d:4b45:0:b0:2f6:3930:fa7f with SMTP id w5-20020a5d4b45000000b002f63930fa7fmr8345977wrs.7.1682089215832; Fri, 21 Apr 2023 08:00:15 -0700 (PDT) Received: from [192.168.0.160] ([170.253.51.134]) by smtp.gmail.com with ESMTPSA id m1-20020a7bca41000000b003f179fc6d8esm4962146wml.44.2023.04.21.08.00.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Apr 2023 08:00:15 -0700 (PDT) Message-ID: <7823f94b-ce59-2bef-51aa-fb0f6fad39ec@gmail.com> Date: Fri, 21 Apr 2023 17:00:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used Content-Language: en-US From: Alejandro Colomar To: Eric Blake Cc: GNU libc development , austin-group-l@opengroup.org, GCC , Zack Weinberg References: <20230330171310.12330-1-alx@kernel.org> <9b528ba9-e1c6-1c03-8ec7-177c4dc66e19@gmail.com> <7396024c-62d4-a19c-b7bc-e24a9d4bcb31@gmail.com> <6fdadcff-95a2-44fe-9453-d0200822e01e@app.fastmail.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Mq0scITetDO9rdT0fk4BscA3" X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Mq0scITetDO9rdT0fk4BscA3 Content-Type: multipart/mixed; boundary="------------i0lpwZU0CmgEJeDM6OmHBk3f"; protected-headers="v1" From: Alejandro Colomar To: Eric Blake Cc: GNU libc development , austin-group-l@opengroup.org, GCC , Zack Weinberg Message-ID: <7823f94b-ce59-2bef-51aa-fb0f6fad39ec@gmail.com> Subject: Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used References: <20230330171310.12330-1-alx@kernel.org> <9b528ba9-e1c6-1c03-8ec7-177c4dc66e19@gmail.com> <7396024c-62d4-a19c-b7bc-e24a9d4bcb31@gmail.com> <6fdadcff-95a2-44fe-9453-d0200822e01e@app.fastmail.com> In-Reply-To: --------------i0lpwZU0CmgEJeDM6OmHBk3f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/21/23 16:58, Alejandro Colomar wrote: > Hi Eric, >=20 > On 4/14/23 18:08, Zack Weinberg via Libc-alpha wrote: >> On 2023-04-06 3:37 PM, Eric Blake wrote: >>> Since Issue 7 is tied to C99, and Issue 8 will be tied to C17, both o= f >>> which use the same section number despite being a different edition o= f >>> the C standard, being that specific may work. Or, we might try >>> something focusing more on wording instead of document location, as >>> in: >>> >>> Additionally, the structures shall be defined in such a way that the >>> compiler treats an access to the stored value of the sa_family_t >>> member of any of these structures, via an lvalue expression whose typ= e >>> involves any other one of these structures, as permissible even if th= e >>> types involved would not otherwise be deemed compatible with the >>> effective type of the object ultimately being accessed. >=20 > The wording I see in > doesn't seem to cover the case of aliasing a sockaddr_storage as a > protocol-specific address for setting other members. >=20 > Aliasing rules don't allow one to declare an object of type > sockaddr_storage and then fill the structure as if it were another > structure, even if alignment and size are correct. We would need > some wording that says something like: >=20 > When a pointer to a sockaddr_storage structure is first aliased as a > pointer to a protocol-specific address structure, the effective type > of the object will be set to the protocol-specific structure. >=20 > This is similar to what happens when malloc(3) is assigned to a > non-character type. That's a big hammer, but it does the job. Maybe > we would need some looser language? I CCd GCC, in case they have > concerns about this wording. >=20 > Cheers, > Alex >=20 >> >> I quite like this way of putting it. It subsumes both what I wrote an= d=20 >> the related potential headache with deciding whether the sa_family_t=20 >> field is considered an object or just a range of bytes within a larger= =20 >> object. >> >> zw >=20 For the man pages, I've rewritten it to the following: $ git diff diff --git a/man3type/sockaddr.3type b/man3type/sockaddr.3type index 2fdf56c59..e610aa0f5 100644 --- a/man3type/sockaddr.3type +++ b/man3type/sockaddr.3type @@ -117,6 +117,14 @@ .SH HISTORY was invented by POSIX. See also .BR accept (2). +.PP +These structures were invented before modern ISO C strict-aliasing rules= =2E +If aliasing rules are applied strictly, +these structures would be impossible to use +without invoking Undefined Behavior (UB). +POSIX Issue 8 will fix this by requiring that implementations +make sure that these structures +can be safely used as they were designed. .SH NOTES .I socklen_t is also defined in I guess this is simple enough that it should work as documentation. --=20 GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5 --------------i0lpwZU0CmgEJeDM6OmHBk3f-- --------------Mq0scITetDO9rdT0fk4BscA3 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmRCpP4ACgkQnowa+77/ 2zLdnw//ZIWEYJWb/wRD7nqvhhAheG3TUueKdXRSFXfiHWdnJiJEVo+oEVNzf5k+ sJuPhJYFTH8Df7qWfhG4JHLJrBfI59mgo+xu2tZnLBsGoSvtZfq3PDWbgHhzysGI EUWduNjsRjfStWgKHWr0RHzPwkJKwU7/v7EFXDG8qXQ4xtrb9c1SKDiVOZJx0nCi +DgLea4XhMNx7iWs+CDZUwmdedba1+ao2GbqNUxDogsJFGM+EX4MKv5CqTxIpZIg MOMsyxR6AxBX6IAEcRHrkf+ZK/f3f+UiYWaH8fmyCPTCDnhx5FAUgyiWx4drC2Hy F2ddETBlEf52n4lIgmZPcFevC1l8D3yV/GtXDYSXSOo5YBoAwZf5XHH4ZzAm2BYL irpq3MEjvS0PL06obutwxXbJmdNvpr/Jb8RQgh6q8nClBMmLgqvBT1pENV9yDqqw VtOv/11KnZUeVt+GZ5MN6gBNqSWXeXA5oP7CDxfP52K1NVSyhywAyK8/6X61MhY3 OOkD+Bxdl7HjQdBTNfiEzBI8CYlDnqkiHvwYEezkW/7jYtCgiSs/AAH6a4v4yWAd ohc8mLuQwMv0d7FBqGmpS6gltXW/QHP4m1dom3kO6dVPBA2mgdOCzfRnLmjwiacQ jSNhWfMvtQzQPUJsgTkL/cNh81Y3ZdU8mR1DhxuOYEoPHdSMags= =Uren -----END PGP SIGNATURE----- --------------Mq0scITetDO9rdT0fk4BscA3--