Corentin,
I am not sure that I get your example correctly.

on Sat, 12 Feb 2022 11:09:26 +0100 you (Corentin via Liaison
<liaison_at_[hidden]>) wrote:

> My understanding of the issue was as follows:
> There is a thread_local which is a C++ type (thereby not extern) ,
> passed to a C function, from within a C++ function.
> Such thread_local could be declared at function scope.
>
> struct S {
> S();
> };

This type can never be properly used as such by a C function, can't it?

So what a C TU should see at most is a `struct S` forward
declaration. Showing C a `struct` definition that lies about the fact
that this has a constructor is an error.

> extern "C" {
> void foo(S*);
> static thread_local S s; // would be okay, with different semantics
> (eager initialization)
> };
>
>
> void f() {
> /* extern "C" */ static thread_local S s; // Do we care to support
> that ? foo(&s);
> }

This function can't be written in C, because C wouldn't know about
the constructor.

> Here I don't think users will necessarily want to put f in the extern
> "C" scope, for example.
> The variable needs to be in an extern "C" scope, not necessarily the
> enclosing function

You'd have to have C linkage for `f` if you'd want to call it from C,
but the implementation of `f` should always be made in C++, because
`struct S` is a type that C can't handle.

Jₑₙₛ

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::