A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1845 ====================================================================== Reported By: ralfjung Assigned To: ====================================================================== Project: 1003.1(2024)/Issue8 Issue ID: 1845 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Ralf Jung Organization: User Reference: Section: exit Page Number: unknown Line Number: unknown Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2024-07-22 16:38 UTC Last Modified: 2024-07-26 22:28 UTC ====================================================================== Summary: Status of the thread-safety of exit is confusing ======================================================================
---------------------------------------------------------------------- (0006850) dalias (reporter) - 2024-07-26 22:28 https://austingroupbugs.net/view.php?id=1845#c6850 ---------------------------------------------------------------------- The functionality Carlos mentions (calling exit from an atexit handler to change exit status to reflect a newly encountered error) is definitely appealing, but the reason I'm hesitant to try to standardize it is that it's hard to define what should happen regarding the remaining atexit handlers and global dtors (the latter of which are outside the scope of this standard). Programs can already do this now by calling _exit/_Exit, but in that case any remaining handlers/dtors do not run, and stdio flush and position sync does not happen. The natural behavior would be that execution of handlers picks up with the next to be called after the one which called exit. This is not hard to implement for atexit handlers, but real-world implementations also deal with global dtors from languages where they are a thing, or as an extension to the C language or platform ABI. The way they are typically implemented, the implementation of the exit function cannot see the boundary between individual dtor calls, and might only see a single atexit-handler-like call for the entire program's dtors, or one per shared library or similar. This means the scope of which, if any, remaining dtors might execute after one calls exit is entirely dependent on implementation details, and thus not suitable for standardization. If there is desire to standardize a behavior for calling exit from an atexit handler, I would urge that we do it only for genuine abstract-machine-level atexit handlers, and leave the case where exit is called from a global dtor or any other context in the exiting thread undefined. (Since such contexts are outside of the scope of this standard anyway, I think from a standards perspective this doesn't require any special action, but it is something implementors need to think about to ensure they don't try to make promises they can't keep.) Issue History Date Modified Username Field Change ====================================================================== 2024-07-22 16:38 ralfjung New Issue 2024-07-22 16:38 ralfjung Name => Ralf Jung 2024-07-22 16:38 ralfjung Section => exit 2024-07-22 16:38 ralfjung Page Number => unknown 2024-07-22 16:38 ralfjung Line Number => unknown 2024-07-24 19:05 dalias Note Added: 0006842 2024-07-24 19:34 ralfjung Note Added: 0006843 2024-07-26 12:26 carlos Note Added: 0006846 2024-07-26 12:37 enh Note Added: 0006847 2024-07-26 12:39 wakely Note Added: 0006848 2024-07-26 20:50 carlos Note Added: 0006849 2024-07-26 22:28 dalias Note Added: 0006850 ======================================================================
