> On Aug 9, 2023, at 12:21 PM, Michael Matz <m...@suse.de> wrote:
>
> 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 ...
Yes, you are right. My mistake -:)
>
>> 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').
right.
>
> 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.
The sizeof() of a structure with FAM is defined as: (after I searched online,
I think that the one in Wikipedia is the most reasonable one):
https://en.wikipedia.org/wiki/Flexible_array_member
======
Effect on struct size and padding
The sizeof operator on such a struct gives the size of the structure as if the
flexible
array member were empty. This may include padding added to accommodate the
flexible member; the compiler is also free to re-use such padding as part of
the array itself.[2]
It is common to allocate sizeof(struct) + array_len*sizeof(array element)
bytes.
This is not wrong, but it may allocate a few more bytes than necessary: the
compiler
may be re-purposing some of the padding that is included in sizeof(struct).
Should
this be a concern, macros are available[3] to compute the minimum size while
ensuring that the compiler's padding is not disrupted.
As the array may start in the padding before the end of the structure, its
content
should always be accessed via indexing (arr[i]) or offsetof, not sizeof.
======
By definition, the sizeof() of a struct with FAM might not be the same as the
non-FAM one.
i.e, for the following two structures, one with FAM, the other with fixed array:
struct foo_flex { int a; short b; char t[]; } x = { .t = { 1, 2, 3 } };
struct foo_fix {int a; short b; char t[3]; }
With current GCC:
sizeof(foo_flex) == 8
sizeof(foo_fix) == 12
I think that the current behavior of sizeof for structure with FAM in GCC is
correct.
The major issue is what was pointed out by Martin in the previous email:
Whether using the following formula is correct to compute the allocation?
sizeof(struct foo_flex) + N * sizeof(foo->t);
As pointed out in the wikipedia, the value computed by this formula might
be bigger than the actual size since “sizeof(struct foo_flex)” might include
paddings that are used as part of the array.
So the more accurate formula should be
offset(struct foo_flex, t[0]) + N * sizeof(foo->t);
With GCC, offset(struct foo_flex,t[0]) == 6, which is also correct.
> 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.
For the question, whether the compiler needs to allocate paddings after the FAM
field,
I don’t know the answer, and it’s not specified in the standard either.
Does it matter?
>
> 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.
Sizeof by definition is return the size of the TYPE, not the size of the
allocated object.
Another thing I need to point out is, a structure with FAM cannot be an
element of an array.
>
> 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.
Currently, GCC’s __builtin_object_size use the following formula to compute the
object size for
The structure with FAM:
offset(struct foo_flex, t[0]) + N * sizeof(foo->t);
I think it’s correct.
I think that the users might need to use this formula to compute the allocation
size for a structure with FAM too.
Qing
>
>
> Ciao,
> Michael.
