在 2021-04-26 04:20, Martin Storsjö 写道:
mismatches - at_quick_exitThe exact behaviour for cases 3-5 differ between whether the two are linked dynamically or statically against the CRT. I'm not sure if all the nuances are worth mimicing though. (A function registered with at_quick_exit within the DLL isn't called when quick_exit is called, regardless of whether the main executable or the DLL calls it.)However - if a DLL does at_quick_exit, and the DLL later is unloaded, we might have an issue if we go with this kind of patch... But the MSVC behaviour doesn't seem entirely consistent either?Regarding your patch, it fails to build with clang due to function type
takes an _PVFV, not an _onexit_t. (I also see that ucrtbase_compat.c currently is wrong about this, it declares _crt_atexit with the wrong type of parameter. I can send a standalone patch that fixes that.)
The purpose of `quick_exit()` is to just call `_Exit()`, but also allow users to perform some custom cleanup, without invoking any static or thread_local destructors.
So personally, I think that quick_exit callbacks registered by a DLL should be discarded when the DLL is unloaded, because if otherwise the process calls `quick_exit()`, those internal pointers will point to deallocated memory.
So, `atexit()` registers callbacks that will be invoked when a DLL is unloaded, and `at_quick_exit()` registers callbacks that will be invoked upon process termination, does it make any sense for a DLL to call the latter? Probably, but only for DLLs that are residential until a process terminates. I think it's of course worth something.
-- Best regards, Liu Hao
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
