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).
signature.asc
Description: OpenPGP digital signature
