https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105684
--- Comment #3 from sagebar at web dot de ---
>The issue is that 'result->data0.a' is (*result).data0.a, and so to GCC you are
>accessing an object of type 'obj' for which there isn't enough allocated space.
Technically true, and yes: not dereferencing `result` while it's still a
`struct obj` makes the warning go away:
```
- result->kind = 0;
- result->data0.a = 1;
+ *(unsigned long long *)((char *)result + __builtin_offsetof(struct obj,
kind)) = 0;
+ *(unsigned long long *)((char *)result + __builtin_offsetof(struct obj,
data0.a)) = 1;
```
But that's like saying `int x = obj->field;` is the same as `int x = ({
typeof(*obj) c = *obj; c.field; })` (i.e. accessing 1 field is like accessing
_all_ fields) -- They're just not the same: accessing a single field simply
doesn't cause the rest of the containing struct to also be loaded (if there's
some weird arch where it does ???, fine; but then this should be an
arch-specific warning).
>A workaround might be to declare 'obj' as
>
>struct obj {
> unsigned long long kind;
> unsigned long long data[];
>};
>
>if in your case all data is really uniform 'unsigned long long'. There's
>no way to union several different typed flexarrays though.
It would for the demo-code, but that's not the context where I encountered this
problem in the real world. For reference, the following is the "typed
variant"-style struct which lead me to create this bug report:
https://github.com/GrieferAtWork/KOSmk4/blob/master/kos/src/kernel/moddbx/include/ctype.h#L193
I simply crafted the minimal viable code that still causes the warning for the
sake of making this bug report.
