[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};

["pascal_cuoq at hotmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956

--- Comment #13 from Pascal Cuoq <pascal_cuoq at hotmail dot com> ---
@Martin

I completely agree with comment 12, however about the last paragraph, I would
like to point out that for purposes of memcpy'ing to or from such a struct with
initialized FAM, it is enough to recommend that programmers use the simple
formula “offsetof(struct foo, t) + n * sizeof(char)” (or “offsetof(struct foo,
t[n])”. The part that is not copied is the part that they did not intend to use
when they chose the initializer of the FAM, and that they cannot portably use
because of the padding that may or may not exist for a different target
architecture.

So since:

First, GCC currently does not always reserve enough room to allow “memcpy(…, …,
sizeof(struct foo) + n * sizeof(char))”, and 

second, using the time-proven formula as argument of malloc technically does
not always allocate enough space to make it valid to access p->t[n-1] according
to the strict interpretation of the words “it behaves as if that member were
replaced with the longest array (with the same element type) that would not
make the structure larger than the object being accessed”,

we might as well start recommending that C programmers use “offsetof(struct
foo, t) + n * sizeof(char)” as argument of memcpy, and either clarify the
meaning of the words “it behaves as if…” in the C standard or prepare for a
very unpleasant discussion when we have to tell them the formula they have to
use as argument of malloc.