On Fri, Sep 18, 2020 at 3:40 PM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
>
> Ouch, offsetof() and sizeof() will give different results in the
> presence of alignment padding.
Indeed. But from an allocation standpoint, the offsetof()+size is I
think the correct size. The padding at the end makes very little sense
for something like "struct_size()".
Padding at the end is required for sizeof() for a very simple reason:
arrays. The "sizeof()" needs to be aligned to the alignment of the
entry, because if it isn't, then the standard C array traversal
doesn't work.
But you cannot sanely have arrays of these structures of variable size
entries either - even if standard C cheerfully allows you to declare
them (again: it will not behave like a variable sized array, it will
behave like a zero-sized one).
That was in fact one of the test-cases that I submitted to the sparse
list - the insanity of allowing arrays of structures that have a
flexible array at the end is just the C standard being confused. The C
standard may allow it, but I don't think we should allow it in the
kernel.
Oh, I can see why somebody would want to have an array of those things
- exactly because they want to have some "initializer _without_ the
flexible array part", and they actually don't want that variably-sized
array at all for that case.
But I'm pretty sure we really really don't want that kind of oddities
in the kernel. If we really want a separate "struct head_struct", then
I think we should do so explicitly, and have something like
struct real_struct {
// Unnamed head struct here
struct head_struct {
,,,,
};
unsigned int variable_array[];
};
and if you want the part without the flexible array at the end, then
you use that "struct head_struct".
Instead of depending on the imho broken model of the C standard that
says "in lots of cases, we'll just silently make that flexible array
be a zero-sized one".
Linus
