A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=728 ====================================================================== Reported By: dalias Assigned To: ====================================================================== Project: 1003.1(2013)/Issue7+TC1 Issue ID: 728 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Rich Felker Organization: musl libc User Reference: Section: XSH 2.4.3 Signal Actions Page Number: unknown Line Number: unknown Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2013-08-05 15:16 UTC Last Modified: 2023-08-14 15:57 UTC ====================================================================== Summary: Restrictions on signal handlers are both excessive and insufficient ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0000733 Volatile qualification of sig_atomic_t ... ======================================================================
---------------------------------------------------------------------- (0006430) geoffclare (manager) - 2023-08-14 15:57 https://austingroupbugs.net/view.php?id=728#c6430 ---------------------------------------------------------------------- On Issue 8 draft 3 page 516 line 18330 section 2.4.3, change:<blockquote>the behavior is undefined if the signal handler refers to any object other than <i>errno</i> with static or thread storage duration that is not a lock-free atomic object, other than by assigning a value to an object declared as <b>volatile sig_atomic_t</b>, or if the signal handler calls any function or function-like macro defined in this standard other than one of the functions and macros specified below as being async-signal-safe.</blockquote>to:<blockquote>the behavior is undefined if:<ul><li>The signal handler refers to any object other than <i>errno</i> with static or thread storage duration that is not a lock-free atomic object, and not a non-modifiable object (for example, string literals, objects that were defined with a const-qualified type, and objects in memory that is mapped read-only), other than by assigning a value to an object declared as <b>volatile sig_atomic_t</b>, unless the previous modification (if any) to the object happens before the signal handler is called and the return from the signal handler happens before the next modification (if any) to the object.</li> <li>The signal handler calls any function or function-like macro defined in this standard other than one of the functions and macros specified below as being async-signal-safe.</li></ul></blockquote> On Issue 8 draft 3 page 2049 line 67324 section signal(), change:<blockquote>the behavior is undefined if the signal handler refers to any object [CX]other than <i>errno</i>[/CX] with static or thread storage duration that is not a lock-free atomic object, other than by assigning a value to an object declared as <b>volatile sig_atomic_t</b>, or if the signal handler calls any function defined in this standard other than [CX]one of the functions listed in Section 2.4 (on page 511)[/CX].</blockquote>to:<blockquote>the behavior is undefined if:<ul><li>The signal handler refers to any object [CX]other than <i>errno</i>[/CX] with static or thread storage duration that is not a lock-free atomic object, [CX]and not a non-modifiable object (for example, string literals, objects that were defined with a const-qualified type, and objects in memory that is mapped read-only)[/CX], other than by assigning a value to an object declared as <b>volatile sig_atomic_t</b>, [CX]unless the previous modification (if any) to the object happens before the signal handler is called and the return from the signal handler happens before the next modification (if any) to the object[/CX].</li> <li>The signal handler calls any function defined in this standard other than [CX]one of the functions listed in Section 2.4 (on page 511)[/CX].</li> </ul></blockquote> Issue History Date Modified Username Field Change ====================================================================== 2013-08-05 15:16 dalias New Issue 2013-08-05 15:16 dalias Name => Rich Felker 2013-08-05 15:16 dalias Organization => musl libc 2013-08-05 15:16 dalias Section => XSH 2.4.3 Signal Actions 2013-08-05 15:16 dalias Page Number => unknown 2013-08-05 15:16 dalias Line Number => unknown 2013-08-05 15:18 dalias Note Added: 0001699 2013-08-15 15:36 eblake Relationship added related to 0000733 2013-09-20 18:05 dalias Note Added: 0001838 2013-09-20 18:17 eadler Issue Monitored: eadler 2013-10-07 22:43 dalias Note Added: 0001863 2023-01-26 10:46 geoffclare Note Added: 0006138 2023-08-14 15:57 geoffclare Note Added: 0006430 ======================================================================
