Am Donnerstag, dem 10.08.2023 um 16:42 +0200 schrieb Jakub Jelinek:
> On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
> > Am Donnerstag, dem 10.08.2023 um 13:59 +0000 schrieb Qing Zhao:
> > >
> > > > On Aug 10, 2023, at 2:58 AM, Martin Uecker <muec...@gwdg.de> wrote:
> > > >
> > > > Am Mittwoch, dem 09.08.2023 um 20:10 +0000 schrieb Qing Zhao:
> > > > >
> > > > > > On Aug 9, 2023, at 12:21 PM, Michael Matz <m...@suse.de> wrote:
> > > >
> >
> > > > I am not sure for the reason given above. The following
> > > > code would not work:
> > > >
> > > > struct foo_flex { int a; short b; char t[]; } x;
> > > > x.a = 1;
> > > > struct foo_flex *p = malloc(sizeof(x) + x.a);
> > > > if (!p) abort();
> > > > memcpy(p, &x, sizeof(x)); // initialize struct
> > > >
> > > Okay.
> > > Then, the user still should use the sizeof(struct foo_flex) + N *
> > > sizeof(foo->t) for the allocation, even though this might allocate more
> > > bytes than necessary. (But this is safe)
> > >
> > > Let me know if I still miss anything.
> >
> > The question is not only what the user should use to
> > allocate, but also what BDOS should return. In my
> > example the user uses the sizeof() + N * sizeof
> > formula and the memcpy is safe, but it would be flagged
> > as a buffer overrun if BDOS uses the offsetof formula.
>
> BDOS/BOS (at least the 0 level) should return what is actually
> allocated for the var, what size was passed to malloc and if it
> is a var with flex array member with initialization what is actually the
> size on the stack or in .data/.rodata etc.
Agreed.
But what about a struct with FAM with the new "counted_by" attribute
if the original allocation is not visible?
Martin
> And for 1 level the same unless it is just access to some element, then
> it should be capped by the size of that element.
>
