[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260311040125.GB1827@brightrain.aerifal.cx>
Date: Wed, 11 Mar 2026 00:01:25 -0400
From: Rich Felker <dalias@...c.org>
To: Thorsten Glaser <tg@...bsd.de>
Cc: musl@...ts.openwall.com
Subject: Re: Question about flexible array
On Mon, Aug 11, 2025 at 10:42:29AM -0400, Rich Felker wrote:
> On Mon, Jun 17, 2024 at 04:29:35AM +0000, Thorsten Glaser wrote:
> > 樊鹏 dixit:
> >
> > >The reason is a difference between gcc and g++:
> > >
> > >Flexible array members are not officially part of C++.
> > >Flexible array members were officially standardized in C99.
> >
> > >/usr/include/bits/signal.h:35:23: error: flexible array member 'mcontext_t::__extcontext' not at end of 'struct tbb::detail::r1::coroutine_type'
> >
> > No, that’s not the problem here (the compiler allows that).
> >
> > The problem is this, in oneTBB itself:
> >
> > struct coroutine_type {
> > coroutine_type() : my_context(), my_stack(), my_stack_size() {}
> > ucontext_t my_context;
> > void* my_stack;
> > std::size_t my_stack_size;
> > };
> >
> > There’s a double problem here. One is the ordering. Changing to…
> >
> > struct coroutine_type {
> > coroutine_type() : my_context(), my_stack(), my_stack_size() {}
> > void* my_stack;
> > std::size_t my_stack_size;
> > ucontext_t my_context;
> > };
> >
> > … would fix that, but I *bet* that the surrounding code allocates
> > its struct coroutine_type by a fixed size and copies my_context
> > by sizeof(ucontext_t), which necessarily does not include the FAM.
> >
> > I’m not sure if it is even permissible for ucontext_t to contain
> > a FAM; perhaps instead you need to figure out the exact or a
> > maximum size and change the declaration (and the ABI, most likely)
> > to that?
> >
> > Otherwise, all that’s left is to forbid userspace the copying of
> > ucontext_t, which probably won’t fly…
>
> You can copy it, but there's no guarantee that the copy will be usable
> for the same purposes the original was. However in this case I don't
> think it matters. If they're using the ucontext for synchronous
> coroutines, the vast majority of it, including all of the optional
> vector state or whatever, is garbage; only the call-saved part of the
> register file (equivalent to a jmp_buf) is relevant.
Is this something that needs to be fixed? I don't recall where but I
think it was raised somewhere else, that there doesn't seem to be
anywhere to store the call-saved fpu registers when implementing the
ucontext functions...
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
