Hello,
On Wed, 9 Aug 2023, Qing Zhao wrote:
> Although this is an old FAM related issue that does not relate to my current
> patch
> (and might need to be resolved in a separate patch). I think that it’s
> necessary to have
> more discussion on this old issue and resolve it.
>
> The first thing that I’d like to confirm is:
>
> What the exact memory layout for the following structure x?
>
> struct foo { int a; short b; char t[]; } x = { .t = { 1, 2, 3 } };
>
> And the key that is confusing me is, where should the field “t” start?
>
> A. Starting at offset 8 as the following:
>
> a 4-bytes
> b 2-bytes
> padding 2-bytes
> t 3-bytes
Why should there be padding before 't'? It's a char array (FAM or not),
so it can be (and should be) placed directly after 'b'. So ...
> B. Starting at offset 6 as the following:
>
> a 4-bytes
> b 2-bytes
> t 3-bytes
... this is the correct layout, when seen in isolation. The discussion
revolves around what should come after 't': if it's a non-FAM struct (with
t[3]), then it's clear that there needs to be padding after it, so to pad
out the whole struct to be 12 bytes long (for sizeof() purpose), as
required by its alignment (due to the int field 'a').
So, should the equivalent FAM struct also have this sizeof()? If no:
there should be a good argument why it shouldn't be similar to the non-FAM
one.
Then there is an argument that the compiler would be fine, when allocating
a single object of such type (not as part of an array!), to only reserve 9
bytes of space for the FAM-struct. Then the question is: should it also
do that for a non-FAM struct (based on the argument that the padding
behind 't' isn't accessible, and hence doesn't need to be alloced). I
think it would be quite unexpected for the compiler to actually reserve
less space than sizeof() implies, so I personally don't buy that argument.
For FAM or non-FAM structs.
Note that if one choses to allocate less space than sizeof implies that
this will have quite some consequences for code generation, in that
sometimes the instruction sequences (e.g. for copying) need to be careful
to never access tail padding that should be there in array context, but
isn't there in single-object context. I think this alone should make it
clear that it's advisable that sizeof() and allocated size agree.
As in: I think sizeof for both structs should return 12, and 12 bytes
should be reserved for objects of such types.
And then the next question is what __builtin_object_size should do with
these: should it return the size with or without padding at end (i.e.
could/should it return 9 even if sizeof is 12). I can see arguments for
both.
Ciao,
Michael.
