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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #15 from Martin Uecker --- GCC seems to allocate enough for sizeof(struct foo) + n * sizeof(char) but not for sizeof(struct { int a; char b; char t[n]; }).

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #14 from Martin Uecker --- Maybe. On the other hand, I wonder whether a struct with FAM should not rather always have the same size, and alignment, and representation as the corresponding struct with a conventional array. This

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #13 from Pascal Cuoq --- @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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #12 from Martin Uecker --- The C standard says "However, when a . (or -> ) operator has a left operand that is (a pointer to) a structure with a flexible array member and the right operand names that member, it behaves as if that

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #11 from Richard Biener --- (In reply to Alexander Monakov from comment #8) > (In reply to jos...@codesourcery.com from comment #6) > > For the standard, dynamically allocated case, you should only need to > > allocate enough

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #10 from Andrew Pinski --- (In reply to Alexander Monakov from comment #8) > I think the following testcase indicates that GCC assumes that tail padding > is accessible: Well it aligned accesses are always accessable the

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #9 from Martin Uecker --- Clang as well, but that would be only padding inside the first part without taking into account extra element in the FAM. I am more concert about programmers using the formula sizeof(.) + n * sizeof for

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org ---

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #7 from joseph at codesourcery dot com --- I suppose the question is how to interpret "the longest array (with the same element type) that would not make the structure larger than the object being accessed". The difficulty of

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #6 from joseph at codesourcery dot com --- For the standard, dynamically allocated case, you should only need to allocate enough memory to contain the initial part of the struct and the array members being accessed - not any

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #5 from Martin Uecker --- Clang bug: https://github.com/llvm/llvm-project/issues/62929

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #4 from Martin Uecker --- The concern would be that a program relying on the size of an object being larger may then have out of bounds accesses. But rereading the standard, I am also not not seeing that this is required. (for the

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #3 from Pascal Cuoq --- @Andrew Pinski You don't even need to invoke the fact that this is an extension. GCC could reserve 17 bytes for each variable i of type “int”, and as long as “sizeof i” continued to evaluate to 4 (4 being

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #2

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 Andrew Pinski changed: What|Removed |Added Severity|normal |trivial --- Comment #1 from Andrew