Su

On Fri, Feb 11, 2022 at 10:44 PM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:

> On 11/02/2022 22.39, Corentin wrote:
> >
> >
> > On Fri, Feb 11, 2022 at 10:33 PM Jens Maurer <Jens.Maurer_at_[hidden]
> <mailto:Jens.Maurer_at_[hidden]>> wrote:
> >
> > On 11/02/2022 22.20, Corentin via Liaison wrote:
> >
> > >
> > > I think the most intuitive behavior is if
> > >
> > > extern "C" thread_local S foo;
> > >
> > > behaves just like _Thread_local would do in C and a C++
> type
> > > that requires non-trivial initialization would simply not
> > > be allowed, i.e. it behaves like _Thread_local in clang
> > > in c++ mode.
> >
> > Sounds good to me.
> >
> > - Survives WG14 making thread_local a real keyword.
> >
> > - Requires no collaboration from WG14.
> >
> > - Your header shared between C++ and C already ought to use 'extern
> "C"',
> > so this reduces the footgun surface.
> >
> > - thread_local in C++ with dynamic libraries is already a nightmare
> > (dynamic initialization order, squared), and this nicely sidesteps
> the
> > problem.
> >
> > - If C++ wants to do something on the C++ side (e.g. constdestroy
> or so),
> > it can do so at its own pace.
> >
> > > I agree. Why would you be trying to use a type with
> non-trivial init in common code defined in a header, but so that it does
> different things in C and C++? If you need non-trivial init, define the
> code in a separate C++ transition unit, not in a header.
> > >
> > >
> > > But by that logic, do we want to change the grammar of C++ for
> this narrow scenario?
> >
> > We're not changing the grammar. We're just adding a paragraph of
> restrictions
> > for thread_local. That seems palatable, given that 'extern "C"'
> already
> > causes restrictions for other areas of the C++ syntax.
> >
> >
> > Don't we need to allow extern "C" static? Afaict this would be novel
>
> extern "C" {
> static int x = 1;
> }
>
> works with gcc today.
>

How do you handle local static at function scope?


> Jens
>
>