From: already5chosen@yahoo.com
On Mon, 12 Jan 2026 08:03:31 -0800
Andrey Tarasevich wrote:
> On Mon 1/12/2026 6:28 AM, Michael S wrote:
> >
> > According to C Standard, access to p->table[4] in foo1() is UB.
> > ...
> > Now the question.
> > What The Standard says about foo2() ? Is there UB in foo2() as
> > well?
>
> Yes, in the same sense as in `foo1`.
>
> > gcc code generator does not think so.
>
> It definitely does.
Do you have citation from the Standard?
> However, since this is the trailing array member
> of the struct, GCC does not want to accidentally suppress the classic
> "struct hack". It assumes that quite possibly the pointer passed to
> the function points to a struct object allocated through the "struct
> hack" technique.
That much I understand myself.
p->table plays a role FMA. A lot of code depends on such pattern. It's
rather standard practice in communication programming. Esp. so in C90,
when there were no FMA and in C++ where FMA does not exist even today.
Production compiler like gcc has really no option except to handle
it as expected by millions of programmers.
But I was interested in the "opinion" of C Standard rather than of gcc
compiler.
Is it full nasal UB or merely "implementation-defined behavior"?
>
> Add an extra field after the trailing array and `foo2` will also fold
> into `return 1`, just like `foo1`.
>
> Perhaps there's a switch in GCC that would outlaw the classic "struct
> hack"... But in any case, it is not prohibited by default for
> compatibility with pre-C99 code.
>
gcc indeed has something of this sort : -fstrict-flex-arrays=3
But at the moment it does not appear to affect code generation [in this
particular example].
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
