From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22710 invoked from network); 7 Jul 2023 14:47:00 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Jul 2023 14:47:00 -0000 Received: (qmail 1826 invoked by uid 550); 7 Jul 2023 14:46:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1794 invoked from network); 7 Jul 2023 14:46:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1688741205; x=1689346005; i=nullplan@gmx.net; bh=YNa95BVVYWIxU7NdOuOzv/P7GqMWvY0tzRecOuY+PdY=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=ZZFIrL8i708paa9QsPKoSl1xlPaqL545oGIFIEdNtxd1k2EphQF7j63zhnkf9a995SjGId+ LoWMWYcrmcXM4tZ24vdQ9MYcNTJkL8ehu6eyQhpVypwZB4sk5dE+5t9ncPlrr9qFy/8XNul/L 0A99ybg3nrAfEnDqTGRSrvefR70O8EVHAMWnFE7EqGneYWo41Uf1hubFX9KOYjtOtbT4rGE5h SerKxvPEBZIkCoDxbQ+F4faZ9zhJuqe3jhaz4mlvBefuRpZEHuIQ7AxrMD2rXRCw1TO6duZMy QhLUokHDm+tTUz1npLeuwozqkoBsLGShrW6AvHeiBvIXAEEB/zuA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Fri, 7 Jul 2023 16:46:45 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: <976b592b08c82bd6b1f8834904071db6602f3885.1685534402.git.Jens.Gustedt@inria.fr> <20230625172619.GR4163@brightrain.aerifal.cx> <20230703013744.ndlqmt3f662g6vwl@gen2.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230703013744.ndlqmt3f662g6vwl@gen2.localdomain> X-Provags-ID: V03:K1:DBbF3CqBmw8m7r4WPgnoRVkBZ8rAUCOmAnv58Fcf7NgVH5jf8WT geIyoow2inr7Tijq8XQxtBwaObayj1DbHK6GSTev4rquyUOkgsMwZnYqbxdjSbZL2MnsY2z DkzU8ksIMOwCbJYt2a5Abxbmew9REDQfiXa10EKhT4eUuFewr/S3HbzJeZaZKigAzv79bkd mKc3F1gbiCrIl7CLSLaeA== UI-OutboundReport: notjunk:1;M01:P0:6UjdbFGvWEw=;N+7bjALjvFIbHppOR14ggpCCKgy k/7DLiQwP8OO8hzMP8yqQbxMXqS4yZ3hhSbW7006BsRY1fmBSKGUTs5feFrgXtO5jnKMXepTf /d2s7wpi5oF7jl7jcgTqQVLJbwVO2mF4UprZkDf2uCN63bJrHsS8Mo0LlRcDNeaVW7kPH5qrm AH/T63HiEp84qx9gpOcbkr+W1IEuCyJFrXgTzQrLcWyl6FpPT0vjarBO902EIxubFfglNVv/V GZCH8l8O1RRhs7NcTtV+QkjduV4n23TTSwJ6bh5mZWa33u8PwmIFAlPuqHbQ6+kPmaG3VY75S SvpPi+IacYC/ZrX9ly4uN7a2KOOz6IlfAHRwCqQssG/pt40Jj16JXZxNXvZ8WnYyi4IaHg6U5 0mBSn0tU/y0XcFV6sx35LnKcC7ctETiP0pGKiv6+X4rVb3tjNhRXe/S84yJ8wkyxioKN97Hkp iyg5TCRkCcZolypYVTKeYozw1QMCVFewuJWvMcpTGnG5opVW4cTL8aAjUFSsUP6zCaMXtiGcM hipO5YtdAOu7E8LxsYnKGPPgMc3/R8cQVYg4H7doHbRVF2EG5QGKDzp9dHWvCkSWzFfEFl60T Hn/6IIte6ShRBj0jMrmkderbQmw6SXlYcAwZL5HSLRc2dSmpMrTN4sHHApBYzd819Okvj8fIE E/Mj0bJQzDMT2w60yEmoo3gApUnpuilkplRtkmtici8wOUqfr3H9ukfyp34VCeM0vfsUrnaqd zvgRdZKn24SB5xQgr+vn+S1melp4mW/O5OIDY/Yv9C1BcquG5l1XvqvEvWiEcclRKZcp0O16c /JSfcqte9XZmveyK9BL6QSwwIwSzQa08vUwDy4RgEZb5Z13ij05jGNTxVTbYB5+RezCsIaHgW ari5i7NguNyCdk/bnmjvQGBCYnypuvAvLINlZL1ByuEMMy+B27VjevwuBGcCSV6JAT/cZgaXc 14yt+VMWBMxAS3nwk8alC+NJ+lM= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [C23 string conversion 1/2] C23: implement the c8rtomb and mbrtoc8 functions Am Mon, Jul 03, 2023 at 07:37:44AM +0600 schrieb NRK: > On Sun, Jun 25, 2023 at 01:26:20PM -0400, Rich Felker wrote: > > A cleaner approach might be a union where the presence of the unsigned > > union member yields the alignment. > > Slightly off-topic, but do you know if this is a standardized guarantee > or not? While I'm aware that this works in practice - sometime ago I > was looking into the standard (c99 IIRC) to see if there's anything that > actually guarantees that or not and couldn't find anything concrete. > > - NRK So this question was rolling around in my head for a while, and I decided to finally look it up. And found something. Basically, I wondered how the behavior could possibly be otherwise. In this case, how could a union possibly have a smaller alignment requirement that one of its members? This cannot work with just special handling for union members, since you can create a pointer to the union member, and then access to the pointer must work correctly, so the pointer must be correctly aligned. The only way I could think of would be to have dynamic padding at the start of the union. Then you could have a union with smaller alignment than one of its members, although the offset of that member would not be a constant. Is that allowed? Grepping through the standards draft (n3096 in this case) I first found 6.5.8.6, which states, among other things: | All pointers to members of the same union object compare equal. Already the alignment thing has been encoded here: If you have a union, and it contains an unsigned and something else, the pointer to the unsigned must be aligned according to the requirement for unsigned (else it would not be a requirement). But then all other members must also be at least as aligned as the unsigned. Then I got to 6.7.2.1.18, which states, among other things | A pointer to a union object, suitably converted, points to each of its | members. [...] There may be unnamed padding at the end of a union | object, but not at its beginning. And there you have it. There can also be no padding at the start. If I dug further, I would probably find that the layout of a union can also not change dynamically, but I shall leave it at that. Basically, ABIs only have the choice to make unions have the maximum alignment of any of its members, or else always have unions have the maximum alignment used on the platform. In any case, a union containing an unsigned must be at least as aligned as the unsigned. HTH, Markus