From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id 5538A3858C83 for ; Fri, 21 Apr 2023 14:58:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5538A3858C83 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-x32a.google.com with SMTP id 5b1f17b1804b1-3f1957e80a2so13302815e9.1 for ; Fri, 21 Apr 2023 07:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682089097; x=1684681097; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=IH5t1xMxQMAj5niQyQSknI/QGYUVDTRX0nvS2kean1Y=; b=CTX0kMS5QQdZPvBN+hmsHrQlCs6gzpXxMZBIQPNjnEFRyD2YTGE5InK2wulwd7BDql zVC9AIwxRR3GAf7CPoBO84bHmAfmvz2kACPV9lABi0G6bp0P1IVfQuK18boR3b9XCfzR JQIJNfZ9XdSda4aaxKemM+ZXNKgKIvT8gX1TIC4BLNAuqUauYzvbhWMU76rWgeRwScG7 l8Il+ONyPnNJqc82QaZ+5oXnet1ufMJoCwJgmVkZvlhmAujf9YNviNv2QjKqJu3sgukm NilGFRiXyigrrbS1u4nflgFv80QPz7ow0ErbgDD0EZo/LPzl+qvm8UakJhl9ljWUnZBS lADQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682089097; x=1684681097; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=IH5t1xMxQMAj5niQyQSknI/QGYUVDTRX0nvS2kean1Y=; b=IMTXgHhc0C38hGg2dR2lk53ThE4xvlCd2btYOD+0GnH0g+PWRSF8TaLeLySm6apcJ1 0+96HjHPDF+KEp8W1lzkTLIL/MaNwGAig+Ar+RCcarraqhdppSrhpX59Ap0KlB8rHib5 M1OTCVtxtW+xaEq4+eF/Ml6a8pljFB6Me2Th5oEasS88J9T+qXMyvnx3bYKCxATQFxmP 7d3avQVtMFRZnZroWRBpfLbbzoRptOzZrSSY5oczemKz91VnQQyrUJnuQHukQlWF3G0Q oriYi8zxzXm+vNxKvMwVDmM2k4Su+ZscxDbbjvWChwXJtD7d/jtRuphaES0tZSzJLs2G LJcw== X-Gm-Message-State: AAQBX9dTUcB+PF34aHfzos2L0ICmi4LAG2T/pkCb1gfNnc0gpNAj2zcC Cbqk6dQzL8UoiB7wdCoKcLg= X-Google-Smtp-Source: AKy350bBE7+zXOo59RlWk531yF5tSoVnHaR1CkRhf18jK1BZve6pMeMUMFsSsp5tXFTanGCm1Qekqw== X-Received: by 2002:a7b:ce86:0:b0:3f1:70d5:1be8 with SMTP id q6-20020a7bce86000000b003f170d51be8mr2372787wmj.15.1682089096855; Fri, 21 Apr 2023 07:58:16 -0700 (PDT) Received: from [192.168.0.160] ([170.253.51.134]) by smtp.gmail.com with ESMTPSA id 25-20020a05600c025900b003ed2c0a0f37sm5025767wmj.35.2023.04.21.07.58.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Apr 2023 07:58:16 -0700 (PDT) Message-ID: Date: Fri, 21 Apr 2023 16:58:08 +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 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> Content-Language: en-US From: Alejandro Colomar In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Ndqtgvl0ngYoP4MlDMtW8vij" X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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) --------------Ndqtgvl0ngYoP4MlDMtW8vij Content-Type: multipart/mixed; boundary="------------Zy9bXJbunz79eyDXgWjv7qk7"; protected-headers="v1" From: Alejandro Colomar To: Eric Blake Cc: GNU libc development , austin-group-l@opengroup.org, GCC , Zack Weinberg Message-ID: 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: --------------Zy9bXJbunz79eyDXgWjv7qk7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Eric, 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 of= >> which use the same section number despite being a different edition of= >> 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 type= >> involves any other one of these structures, as permissible even if the= >> types involved would not otherwise be deemed compatible with the >> effective type of the object ultimately being accessed. 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. 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: 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. 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. Cheers, Alex >=20 > I quite like this way of putting it. It subsumes both what I wrote and= =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 = > object. >=20 > zw --=20 GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5 --------------Zy9bXJbunz79eyDXgWjv7qk7-- --------------Ndqtgvl0ngYoP4MlDMtW8vij 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/2zIFAmRCpIAACgkQnowa+77/ 2zJOww/+NlJSZXWPc84T0zi4WmIQ1Kfglzlmovko2xnbSpJsYTYkXl+Ys9PU/S/E lVNiiMSsiLL2BRzYDP4WYC8y0wqiwjoLrhJDPv+34OeIueCWqmNYzVHT+MQS2v0H AWYmw89dgGjZkmYhUGP1e/2j3hFhLIiC17m+F3CRuH3XeYZ11nwSMtTP9q6ONJlO Mt+EgkwXc88s3zuJrBAxO/xbYa9Sq8GenNNKA0GseW6Qk1m8Hl//lT1t9ozXwNKC faIo39rn84CNO1VOGhILFQ3Y03IDVTN8HUvdwv5SqAlD/j7+p6UY8EnYDxmrp0WB afNxy3LPtwOIGzEyyF7M1iz+qA4QfTs3UQR7EoC8LDpD70ybzIRMNn7X7iaI8VMg 8TQrXCXBQVFNoLxWFk5uhm1UzzckKMIQ9Har8lFi1S9KKV9qqgsMEGYUIkBe6n4U UaVikeJCyTfzA0aNiXGhpCSXYMM2NTN+rUuLasnSvxNUVakZ70FgRrhEvwGYXM6/ CGhfvY/rhDRPZIn/usTpvAzLjm3RorNnWSlB4dPAW5961i5Nn2FVVhZhyJ2nE4g1 y9iCBqelgktOIJRBkRNn0OFnydBqV0EOnQEFYvCAXvAukjy+CxMau3rl4tQxiSaB gAqEUjF5/nytKBvwlK5UvHRg/bePZCtRlVk3qBjn5XUOVc9KbL4= =KFQs -----END PGP SIGNATURE----- --------------Ndqtgvl0ngYoP4MlDMtW8vij--