On 06.07.2020 14:31, Robert Elz wrote:
>     Date:        Sun, 5 Jul 2020 23:11:44 +0200
>     From:        Kamil Rytarowski <ka...@netbsd.org>
>     Message-ID:  <57c15085-dc7d-6c71-1b26-a402839ba...@netbsd.org>
> 
>   | This is extended to the behavior of "at dlclose() or a normal program
>   | termination".
> 
> Extended by whom or what?   What I quoted was from a draft if POSIX issue 8
> which is forthcoming (probably sometime next year).   There is no change
> like the one you postulate.
> 
>   | atexit() is a direct subset of __cxa_atexit() and they are asked to
>   | share the same internal implementation.
> 
> That's fine.   What __cta_atexit() does, and how it does it, is its
> own business - but what atexit does is specified, and users are entitled
> to reply upon it working the way the standard says it works.
> 
> That some implementations (apparently) don't just means that somewhere,
> someone was lazy, and didn't do what the inventors of __cta_atexit() did,
> and define a new function to implement new functionality.
> 
> Copying that would be a huge disservice to everyone.
> 
> kre
> 

Can we add atdlclose()? (I don't have strong opinions on the final name.)

int atdlclose(void (*function)(void *));

void* as a parameter is important.

> Funny that you should mention Windows. To quote MSDN:
>
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/atexit?view=vs-2019
>
>    "The code in the atexit function should not contain any dependency on
>    any DLL which could have already been unloaded when the atexit function
>    is called."
>
> ...and Microsoft specifically introduced a different function for that
> purpose.
>

Windows uses per-DLL atexit stacks and they work similarly to GNU/Linux.
They are safe to use in loadable modules, unless they cross call
functions from other DLLs that could be gone (this does not include
itself, which is safe).

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to