#include <iostream>

using namespace std;

int main()
{ auto lambda = []( int a ) -> int
{
thread_local int i = 0;
return i++ + a;
};
int (__fastcall *volatile pFnFastcall)( int ) = lambda;
int (__stdcall *volatile pFnStdcall)( int ) = lambda;
cout << pFnFastcall( 10 ) << endl;
cout << pFnStdcall( 9 ) << endl;
}

Don't compile it yourself, just guess.

Bonita Montero <Bonita.Montero@gmail.com> writes:

> #include <iostream>
>
> using namespace std;
>
> int main()
> {
> auto lambda = []( int a ) -> int
> {
> thread_local int i = 0;
> return i++ + a;
> };
> int (__fastcall *volatile pFnFastcall)( int ) = lambda;
> int (__stdcall *volatile pFnStdcall)( int ) = lambda;
> cout << pFnFastcall( 10 ) << endl;
> cout << pFnStdcall( 9 ) << endl;
> }
>
> Don't compile it yourself,

An easy injunction to follow since it has syntax errors! Presumably
those undeclared identifiers (or proprietary keywords?) have some
meaning to your compiler.

> just guess.

--
Ben.

In article <87lec95n0t.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> #include <iostream>
>>
>> using namespace std;
>>
>> int main()
>> {
>> auto lambda = []( int a ) -> int
>> {
>> thread_local int i = 0;
>> return i++ + a;
>> };
>> int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>> int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>> cout << pFnFastcall( 10 ) << endl;
>> cout << pFnStdcall( 9 ) << endl;
>> }
>>
>> Don't compile it yourself,
>
>An easy injunction to follow since it has syntax errors! Presumably
>those undeclared identifiers (or proprietary keywords?) have some
>meaning to your compiler.

Actually, it is pretty easy to answer OP's question. Here's what it
prints:

<stdin>: In function 'int main()':
<stdin>:12:8: error: '__fastcall' was not declared in this scope
<stdin>:12:3: error: expected primary-expression before 'int'
<stdin>:13:8: error: '__stdcall' was not declared in this scope
<stdin>:13:3: error: expected primary-expression before 'int'
<stdin>:14:11: error: 'pFnFastcall' was not declared in this scope
<stdin>:15:11: error: 'pFnStdcall' was not declared in this scope

And it is, in theory at least, possible to predict that without using a
compiler (though, truth to be told, I did cheat and use the compiler).

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/InsaneParty

Am 11.10.2023 um 15:03 schrieb Ben Bacarisse:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> #include <iostream>
>>
>> using namespace std;
>>
>> int main()
>> {
>> auto lambda = []( int a ) -> int
>> {
>> thread_local int i = 0;
>> return i++ + a;
>> };
>> int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>> int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>> cout << pFnFastcall( 10 ) << endl;
>> cout << pFnStdcall( 9 ) << endl;
>> }
>>
>> Don't compile it yourself,
>
> An easy injunction to follow since it has syntax errors! ...

The code compiles with MSVC.

Am 11.10.2023 um 15:12 schrieb Kenny McCormack:

> Actually, it is pretty easy to answer OP's question. Here's what it
> prints:
>
> <stdin>: In function 'int main()':
> <stdin>:12:8: error: '__fastcall' was not declared in this scope
> <stdin>:12:3: error: expected primary-expression before 'int'
> <stdin>:13:8: error: '__stdcall' was not declared in this scope
> <stdin>:13:3: error: expected primary-expression before 'int'
> <stdin>:14:11: error: 'pFnFastcall' was not declared in this scope
> <stdin>:15:11: error: 'pFnStdcall' was not declared in this scope
>
> And it is, in theory at least, possible to predict that without using a
> compiler (though, truth to be told, I did cheat and use the compiler).

Use a compiler which knows __fastcall and __stdcall.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 11.10.2023 um 15:12 schrieb Kenny McCormack:
>
>> Actually, it is pretty easy to answer OP's question. Here's what it
>> prints:
>>
>> <stdin>: In function 'int main()':
>> <stdin>:12:8: error: '__fastcall' was not declared in this scope
>> <stdin>:12:3: error: expected primary-expression before 'int'
>> <stdin>:13:8: error: '__stdcall' was not declared in this scope
>> <stdin>:13:3: error: expected primary-expression before 'int'
>> <stdin>:14:11: error: 'pFnFastcall' was not declared in this scope
>> <stdin>:15:11: error: 'pFnStdcall' was not declared in this scope
>>
>> And it is, in theory at least, possible to predict that without using a
>> compiler (though, truth to be told, I did cheat and use the compiler).
>
>Use a compiler which knows __fastcall and __stdcall.
>

Why?

gcc and clang are far superior.

On 2023-10-11 at 19:41, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 11.10.2023 um 15:12 schrieb Kenny McCormack:
>>
>>> Actually, it is pretty easy to answer OP's question. Here's what it
>>> prints:
>>>
>>> <stdin>: In function 'int main()':
>>> <stdin>:12:8: error: '__fastcall' was not declared in this scope
>>> <stdin>:12:3: error: expected primary-expression before 'int'
>>> <stdin>:13:8: error: '__stdcall' was not declared in this scope
>>> <stdin>:13:3: error: expected primary-expression before 'int'
>>> <stdin>:14:11: error: 'pFnFastcall' was not declared in this scope
>>> <stdin>:15:11: error: 'pFnStdcall' was not declared in this scope
>>>
>>> And it is, in theory at least, possible to predict that without using a
>>> compiler (though, truth to be told, I did cheat and use the compiler).
>>
>> Use a compiler which knows __fastcall and __stdcall.
>>
>
> Why?
>
> gcc and clang are far superior.

The irony is that the compiler that "knows them", also knows to ignore
them. That's why the lambda is compatible with both.

They used to have a meaning for 32-bit Windows.

On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> #include <iostream>
>>
>> using namespace std;
>>
>> int main()
>> {
>> auto lambda = []( int a ) -> int
>> {
>> thread_local int i = 0;
>> return i++ + a;
>> };
>> int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>> int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>> cout << pFnFastcall( 10 ) << endl;
>> cout << pFnStdcall( 9 ) << endl;
>> }
>>
>> Don't compile it yourself,
>
> An easy injunction to follow since it has syntax errors! Presumably
> those undeclared identifiers (or proprietary keywords?) have some
> meaning to your compiler.
>
>> just guess.
>

Afaict, around 99.(9)% sure, Bonita is a troll.

On 10/11/2023 12:41 PM, Chris M. Thomasson wrote:
> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> #include <iostream>
>>>
>>> using namespace std;
>>>
>>> int main()
>>> {
>>>     auto lambda = []( int a ) -> int
>>>     {
>>>         thread_local int i = 0;
>>>         return i++ + a;
>>>     };
>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>     cout << pFnFastcall( 10 ) << endl;
>>>     cout << pFnStdcall( 9 ) << endl;
>>> }
>>>
>>> Don't compile it yourself,
>>
>> An easy injunction to follow since it has syntax errors!  Presumably
>> those undeclared identifiers (or proprietary keywords?) have some
>> meaning to your compiler.
>>
>>> just guess.
>>
>
> Afaict, around 99.(9)% sure, Bonita is a troll.

100% indeed

Am 11.10.2023 um 19:41 schrieb Scott Lurndal:

> Bonita Montero <Bonita.Montero@gmail.com> writes:

>> Use a compiler which knows __fastcall and __stdcall.

> Why?
> gcc and clang are far superior.

In this case it's about functionality, not performance.
And clang-cl supports __fastcall and __stdcall also.

Am 11.10.2023 um 21:41 schrieb Chris M. Thomasson:

>> Bonita Montero <Bonita.Montero@gmail.com> writes:

>>> #include <iostream>
>>>
>>> using namespace std;
>>>
>>> int main()
>>> {
>>>     auto lambda = []( int a ) -> int
>>>     {
>>>         thread_local int i = 0;
>>>         return i++ + a;
>>>     };
>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>     cout << pFnFastcall( 10 ) << endl;
>>>     cout << pFnStdcall( 9 ) << endl;
>>> }
>>>

> Afaict, around 99.(9)% sure, Bonita is a troll.

Yes, because I didn't use a race detector on the above code.

On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> #include <iostream>
>>
>> using namespace std;
>>
>> int main()
>> {
>> auto lambda = []( int a ) -> int
>> {
>> thread_local int i = 0;
>> return i++ + a;
>> };
>> int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>> int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>> cout << pFnFastcall( 10 ) << endl;
>> cout << pFnStdcall( 9 ) << endl;
>> }
>>
>> Don't compile it yourself,
>
> An easy injunction to follow since it has syntax errors! Presumably
> those undeclared identifiers (or proprietary keywords?) have some
> meaning to your compiler.
>
>> just guess.
>

What is 10 * 10? It's one hundred percent that the lovely Bonita is a troll.

Am 13.10.2023 um 05:50 schrieb Chris M. Thomasson:
> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> #include <iostream>
>>>
>>> using namespace std;
>>>
>>> int main()
>>> {
>>>     auto lambda = []( int a ) -> int
>>>     {
>>>         thread_local int i = 0;
>>>         return i++ + a;
>>>     };
>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>     cout << pFnFastcall( 10 ) << endl;
>>>     cout << pFnStdcall( 9 ) << endl;
>>> }
>>>
>>> Don't compile it yourself,
>>
>> An easy injunction to follow since it has syntax errors!  Presumably
>> those undeclared identifiers (or proprietary keywords?) have some
>> meaning to your compiler.
>>
>>> just guess.
>>
>
>
> What is 10 * 10?
> It's one hundred percent that the lovely Bonita is a troll.

O.k., I'll explain it: the lambda is compiled twice for each cal-
ling convention but in contrast to a generic lambda the thread
local variable "i" exists only once for both "instantiations" !
With a generic lambda there would be an "i" for each instanti-
ation of the lambda's calling operator. I thought the people
here should be able to think about that without compiling the
code.
And you call that trolling ...

On 10/11/23 1:22 PM, Bonita Montero wrote:
> Am 11.10.2023 um 15:12 schrieb Kenny McCormack:
>
>> Actually, it is pretty easy to answer OP's question.  Here's what it
>> prints:
>>
>> <stdin>: In function 'int main()':
>> <stdin>:12:8: error: '__fastcall' was not declared in this scope
>> <stdin>:12:3: error: expected primary-expression before 'int'
>> <stdin>:13:8: error: '__stdcall' was not declared in this scope
>> <stdin>:13:3: error: expected primary-expression before 'int'
>> <stdin>:14:11: error: 'pFnFastcall' was not declared in this scope
>> <stdin>:15:11: error: 'pFnStdcall' was not declared in this scope
>>
>> And it is, in theory at least, possible to predict that without using a
>> compiler (though, truth to be told, I did cheat and use the compiler).
>
> Use a compiler which knows __fastcall and __stdcall.
>
>

But ANY program using those, that is to be interpreted as "Standard
C++", has, by the Standard "Undefined Behavior".

So, the answer, when posted as a general "C++" question, is, it does
what ever the implementation wants it to do.

To get your answer, you need to limit the "Language" of the program to
the particular implementation you desire.

I could CORRECTLY state (if I want to go to the effort) that when I
complied the program, its output was "Bonita is a idiot", because that
is what the Damon C++ compiler generated, and it is fully conforming.

(And that answer IS a correct statement).

On 10/13/23 2:50 AM, Bonita Montero wrote:
> Am 13.10.2023 um 05:50 schrieb Chris M. Thomasson:
>> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> #include <iostream>
>>>>
>>>> using namespace std;
>>>>
>>>> int main()
>>>> {
>>>>     auto lambda = []( int a ) -> int
>>>>     {
>>>>         thread_local int i = 0;
>>>>         return i++ + a;
>>>>     };
>>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>>     cout << pFnFastcall( 10 ) << endl;
>>>>     cout << pFnStdcall( 9 ) << endl;
>>>> }
>>>>
>>>> Don't compile it yourself,
>>>
>>> An easy injunction to follow since it has syntax errors!  Presumably
>>> those undeclared identifiers (or proprietary keywords?) have some
>>> meaning to your compiler.
>>>
>>>> just guess.
>>>
>>
>>
>> What is 10 * 10?
>> It's one hundred percent that the lovely Bonita is a troll.
>
>
> O.k., I'll explain it: the lambda is compiled twice for each cal-
> ling convention but in contrast to a generic lambda the thread
> local variable "i" exists only once for both "instantiations" !
> With a generic lambda there would be an "i" for each instanti-
> ation of the lambda's calling operator. I thought the people
> here should be able to think about that without compiling the
> code.
> And you call that trolling ...

And your lack of knowledge of how the standard actually works just shows
how little you really know.

On 2023-10-13, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> O.k., I'll explain it: the lambda is compiled twice for each cal-

I suspect the terminology you're groping for is "inlined".

> ling convention but in contrast to a generic lambda the thread

I don't believe it. It looks like the lambda uses the default calling
convention ("__cdecl"), and is just being misused through the wrong
calling convention.

It's possible that inlining will render this consideration
moot, because if the function is inlined, then no actual calls are
happening, and there are no calling conventions.
(Compiling for a target other than x86 also renders it moot, since
the calling convention extensions are ignored on x64 and arm.
Let's assume they are there for a reason, and we are targetting x86).

Inlining is an optimization.

If your code depends on optimization (or lack thereof) in order to have
the semantics you believe it to have, it's wrong.

If the function is actually called through the wrong conventions,
there will be problems. The fastcall call will put the argument value in
a register, whereas the stdcall function will try to take it from the
stack, resulting in the callee accessing some value unrelated to the
argument.

The stdcall might be able to access the argument value, but under
stdcall, the callee is assumed to remove arguments from the stack
which the cdecl callee will not do. That could leave the stack in
sufficiently bad state that main is not able to return.

Or something; why go too deeply into guessing what incorrect code
might be doing, if we're not actually fighting a fire.

That function inlining doesn't proliferate copies of static or
thread_local variables isn't surprising at all; that's needed to
preserve semantics.

It is generic lambdas that stand in contrast. They are a macro-like
mechanism which duplicates code, due to type inference or template
argument deduction. They are also newer.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 11.10.2023 um 19:41 schrieb Scott Lurndal:
>
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>>> Use a compiler which knows __fastcall and __stdcall.
>
>> Why?
>> gcc and clang are far superior.
>
> In this case it's about functionality, not performance.
> And clang-cl supports __fastcall and __stdcall also.

Here, clang reports:

xx.cc:12:7: warning: '__fastcall' calling convention is not supported for this target [-Wignored-attributes]
int (__fastcall *volatile pFnFastcall)( int ) = lambda;
^
xx.cc:13:7: warning: '__stdcall' calling convention is not supported for this target [-Wignored-attributes]
int (__stdcall *volatile pFnStdcall)( int ) = lambda;

so "supported" in the sense that it's not a syntax error.

--
Ben.

Richard Damon <richard@damon-family.org> writes:
>On 10/11/23 1:22 PM, Bonita Montero wrote:
>> Am 11.10.2023 um 15:12 schrieb Kenny McCormack:
>>
>>> Actually, it is pretty easy to answer OP's question.  Here's what it
>>> prints:
>>>
>>> <stdin>: In function 'int main()':
>>> <stdin>:12:8: error: '__fastcall' was not declared in this scope
>>> <stdin>:12:3: error: expected primary-expression before 'int'
>>> <stdin>:13:8: error: '__stdcall' was not declared in this scope
>>> <stdin>:13:3: error: expected primary-expression before 'int'
>>> <stdin>:14:11: error: 'pFnFastcall' was not declared in this scope
>>> <stdin>:15:11: error: 'pFnStdcall' was not declared in this scope
>>>
>>> And it is, in theory at least, possible to predict that without using a
>>> compiler (though, truth to be told, I did cheat and use the compiler).
>>
>> Use a compiler which knows __fastcall and __stdcall.
>>
>>
>
>But ANY program using those, that is to be interpreted as "Standard
>C++", has, by the Standard "Undefined Behavior".

And moreover, they only have different behavior on x86 (32-bit).

On x86_64, ARM64, et alia __fastcall/__stdcall are ignored, even by microsoft compilers.

On 10/13/2023 9:34 AM, Kaz Kylheku wrote:
> On 2023-10-13, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> O.k., I'll explain it: the lambda is compiled twice for each cal-
>
> I suspect the terminology you're groping for is "inlined".
>
>> ling convention but in contrast to a generic lambda the thread
>
> I don't believe it. It looks like the lambda uses the default calling
> convention ("__cdecl"), and is just being misused through the wrong
> calling convention.
>
> It's possible that inlining will render this consideration
> moot, because if the function is inlined, then no actual calls are
> happening, and there are no calling conventions.
> (Compiling for a target other than x86 also renders it moot, since
> the calling convention extensions are ignored on x64 and arm.
> Let's assume they are there for a reason, and we are targetting x86).
>
> Inlining is an optimization.
>
> If your code depends on optimization (or lack thereof) in order to have
> the semantics you believe it to have, it's wrong.
>
> If the function is actually called through the wrong conventions,
> there will be problems. The fastcall call will put the argument value in
> a register, whereas the stdcall function will try to take it from the
> stack, resulting in the callee accessing some value unrelated to the
> argument.
>
> The stdcall might be able to access the argument value, but under
> stdcall, the callee is assumed to remove arguments from the stack
> which the cdecl callee will not do. That could leave the stack in
> sufficiently bad state that main is not able to return.
>
> Or something; why go too deeply into guessing what incorrect code
> might be doing, if we're not actually fighting a fire.
>
> That function inlining doesn't proliferate copies of static or
> thread_local variables isn't surprising at all; that's needed to
> preserve semantics.

Afaict, thread_local should be using the thread that is calling main in
this example.

I should create a new thread for this, but:

Fwiw, actually, I am trying to understand how dtors are called wrt TLS
when a thread is destroyed (aka, join returns) in C++. POSIX and C11
makes this rather easy wrt:

Notice the dtor that we can use wrt (thread local storage) TLS:

https://en.cppreference.com/w/c/thread/tss_create

This is basically how POSIX does it via:

pthread_key_t
_______________
pthread_key_create
pthread_setspecific
pthread_getspecific
pthread_key_delete
_______________

Easy.

>
> It is generic lambdas that stand in contrast. They are a macro-like
> mechanism which duplicates code, due to type inference or template
> argument deduction. They are also newer.
>

On 2023-10-13, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> Afaict, thread_local should be using the thread that is calling main in
> this example.

If the program has not started any threads, so that there is only
the primary thread that starts at main, thread_local could be
replaced by static.

> I should create a new thread for this, but:
>
> Fwiw, actually, I am trying to understand how dtors are called wrt TLS
> when a thread is destroyed (aka, join returns) in C++. POSIX and C11
> makes this rather easy wrt:
>
> Notice the dtor that we can use wrt (thread local storage) TLS:
>
> https://en.cppreference.com/w/c/thread/tss_create
>
> This is basically how POSIX does it via:
>
> pthread_key_t
> _______________
> pthread_key_create
> pthread_setspecific
> pthread_getspecific
> pthread_key_delete
> _______________

The pthread_key_delete function is rarely needed. We would need it in,
say, a dynamically loaded component that is being unloaded.

Usually keys have an indefinite lifetime. The values don't, of course.

In pthread_key_create we can register a destructor function
that is used upon thread death.

This is extremely badly designed in POSIX, because that thread which is
terminated is tasked with the clean-up of the keys: the destructors
run in its context.

While it's performing the clean-up for one key, it might inadvertently
call some code which reinstalls the value for another key.

In recognition of this problem, the API is designed with a silly
iteration mechanism. If the terminating thread has reinstanted
values for any thread specific keys, those are iterated on again
and the destructors are called, up to some number of times.

What you want is to allow the thread to just exit. In that thread's
context, at most you want to do unwinding of its scoped resources.

The thread-specific keys values of a thread should persist until it
has terminated, and then be cleaned up at some later time by
*another* thread. Kind of like a garbage collection pass.

If the thread is pthread_join-ed, the one doing the joining would
be a good candidate. For detached threads, it could be done by some
internal thread, or foisted onto some existing application thread
when it happens to bump into the pthread key API.

That would prevent the need for iterations because, since another
thread is running the destructors, and not the original one,
That other thread can only set its own key values, and not those
of another thread, let alone a dead one.

Some 25 years ago I made a TLS API like that, with the cleanup
done on another thread. It worked well.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/13/2023 7:36 PM, Kaz Kylheku wrote:
> On 2023-10-13, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> Afaict, thread_local should be using the thread that is calling main in
>> this example.
>
> If the program has not started any threads, so that there is only
> the primary thread that starts at main, thread_local could be
> replaced by static.
>
>> I should create a new thread for this, but:
>>
>> Fwiw, actually, I am trying to understand how dtors are called wrt TLS
>> when a thread is destroyed (aka, join returns) in C++. POSIX and C11
>> makes this rather easy wrt:
>>
>> Notice the dtor that we can use wrt (thread local storage) TLS:
>>
>> https://en.cppreference.com/w/c/thread/tss_create
>>
>> This is basically how POSIX does it via:
>>
>> pthread_key_t
>> _______________
>> pthread_key_create
>> pthread_setspecific
>> pthread_getspecific
>> pthread_key_delete
>> _______________
>
> The pthread_key_delete function is rarely needed. We would need it in,
> say, a dynamically loaded component that is being unloaded.
>
> Usually keys have an indefinite lifetime. The values don't, of course.
>
> In pthread_key_create we can register a destructor function
> that is used upon thread death.
>
> This is extremely badly designed in POSIX, because that thread which is
> terminated is tasked with the clean-up of the keys: the destructors
> run in its context.

Sorry for the brief response. Actually, I never had a problem with it in
my code before. However, I have had to debug some code created by
others. Should have some more time tomorrow to code some tests up. Am
curious if some of my C compilers support C11 threads yet like Pelles C:

http://www.smorgasbordet.com/pellesc/

[...]

14.10.2023 05:36 Kaz Kylheku kirjutas:
>
> The thread-specific keys values of a thread should persist until it
> has terminated, and then be cleaned up at some later time by
> *another* thread. Kind of like a garbage collection pass.

So, a destructor of an object which has specifically declared to live in
a single thread only, will be called in some other thread?

Sure, seems very intuitive, what might go wrong!

Am 13.10.2023 um 18:53 schrieb Ben Bacarisse:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Am 11.10.2023 um 19:41 schrieb Scott Lurndal:
>>
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>>> Use a compiler which knows __fastcall and __stdcall.
>>
>>> Why?
>>> gcc and clang are far superior.
>>
>> In this case it's about functionality, not performance.
>> And clang-cl supports __fastcall and __stdcall also.
>
> Here, clang reports:

clang-cl, not clang.

>
> xx.cc:12:7: warning: '__fastcall' calling convention is not supported for this target [-Wignored-attributes]
> int (__fastcall *volatile pFnFastcall)( int ) = lambda;
> ^
> xx.cc:13:7: warning: '__stdcall' calling convention is not supported for this target [-Wignored-attributes]
> int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>
> so "supported" in the sense that it's not a syntax error.
>

Am 13.10.2023 um 18:12 schrieb Richard Damon:
> On 10/11/23 1:22 PM, Bonita Montero wrote:
>> Am 11.10.2023 um 15:12 schrieb Kenny McCormack:
>>
>>> Actually, it is pretty easy to answer OP's question.  Here's what it
>>> prints:
>>>
>>> <stdin>: In function 'int main()':
>>> <stdin>:12:8: error: '__fastcall' was not declared in this scope
>>> <stdin>:12:3: error: expected primary-expression before 'int'
>>> <stdin>:13:8: error: '__stdcall' was not declared in this scope
>>> <stdin>:13:3: error: expected primary-expression before 'int'
>>> <stdin>:14:11: error: 'pFnFastcall' was not declared in this scope
>>> <stdin>:15:11: error: 'pFnStdcall' was not declared in this scope
>>>
>>> And it is, in theory at least, possible to predict that without using a
>>> compiler (though, truth to be told, I did cheat and use the compiler).
>>
>> Use a compiler which knows __fastcall and __stdcall.
>>
>>
>
> But ANY program using those, that is to be interpreted as "Standard
> C++", has, by the Standard "Undefined Behavior".

This is just a Windows program. If you don't like it, don't worry
about it.Others might be able to understand this without Windows,
but you can't.

>
> So, the answer, when posted as a general "C++" question, is, it does
> what ever the implementation wants it to do.
>
> To get your answer, you need to limit the "Language" of the program to
> the particular implementation you desire.
>
> I could CORRECTLY state (if I want to go to the effort) that when I
> complied the program, its output was "Bonita is a idiot", because that
> is what the Damon C++ compiler generated, and it is fully conforming.
>
> (And that answer IS a correct statement).

Am 13.10.2023 um 18:15 schrieb Richard Damon:
> On 10/13/23 2:50 AM, Bonita Montero wrote:
>> Am 13.10.2023 um 05:50 schrieb Chris M. Thomasson:
>>> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>
>>>>> #include <iostream>
>>>>>
>>>>> using namespace std;
>>>>>
>>>>> int main()
>>>>> {
>>>>>     auto lambda = []( int a ) -> int
>>>>>     {
>>>>>         thread_local int i = 0;
>>>>>         return i++ + a;
>>>>>     };
>>>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>>>     cout << pFnFastcall( 10 ) << endl;
>>>>>     cout << pFnStdcall( 9 ) << endl;
>>>>> }
>>>>>
>>>>> Don't compile it yourself,
>>>>
>>>> An easy injunction to follow since it has syntax errors!  Presumably
>>>> those undeclared identifiers (or proprietary keywords?) have some
>>>> meaning to your compiler.
>>>>
>>>>> just guess.
>>>>
>>>
>>>
>>> What is 10 * 10?
>>> It's one hundred percent that the lovely Bonita is a troll.
>>
>>
>> O.k., I'll explain it: the lambda is compiled twice for each cal-
>> ling convention but in contrast to a generic lambda the thread
>> local variable "i" exists only once for both "instantiations" !
>> With a generic lambda there would be an "i" for each instanti-
>> ation of the lambda's calling operator. I thought the people
>> here should be able to think about that without compiling the
>> code.
>> And you call that trolling ...
>
> And your lack of knowledge of how the standard actually works just shows
> how little you really know.

I know that this isn't standard C++.
But this doesn't matter for my question.