mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <>
Subject: Re: [musl] [C23 string conversion 1/2] C23: implement the c8rtomb and mbrtoc8 functions
Date: Fri, 7 Jul 2023 16:46:45 +0200	[thread overview]
Message-ID: <ZKglVT/P1+B6rd63@voyager> (raw)
In-Reply-To: <20230703013744.ndlqmt3f662g6vwl@gen2.localdomain>

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, 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, 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.


  reply	other threads:[~2023-07-07 14:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2023-05-31 14:01 ` Jens Gustedt
2023-06-25 17:26   ` Rich Felker
2023-06-26 10:28     ` Jₑₙₛ Gustedt
2023-07-03  1:37     ` NRK
2023-07-07 14:46       ` Markus Wichmann [this message]
2023-05-31 14:01 ` [musl] [C23 string conversion 2/2] C23: add the new include guards for string.h and wchar.h Jens Gustedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZKglVT/P1+B6rd63@voyager \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).