The following issue has been SUBMITTED. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1905 
====================================================================== 
Reported By:                geoffclare
Assigned To:                
====================================================================== 
Project:                    1003.1(2024)/Issue8
Issue ID:                   1905
Category:                   System Interfaces
Type:                       Clarification Requested
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       Geoff Clare 
Organization:               The Open Group 
User Reference:              
Section:                    2.4.3 
Page Number:                519 
Line Number:                18344 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2025-02-06 14:34 UTC
Last Modified:              2025-02-06 14:34 UTC
====================================================================== 
Summary:                    Conflicting text about async-signal-safety
Description: 
In section 2.4.3 this text at line 18330:<blockquote>If the process is
multi-threaded, or if the process is single-threaded and a signal handler
is executed other than as the result of: <ul><li>The process calling
abort(), raise(), kill(), pthread_kill(), or sigqueue() to generate a
signal that is not blocked</li>
<li> A pending signal being unblocked and being delivered before the call
that unblocked it returns</li></ul>the behavior is undefined
if:<ul><li>[...]</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>
conflicts with this text at line 18414:<blockquote>In the presence of
signals, all functions defined by this volume of POSIX.1-2024 shall behave
as defined when called from or interrupted by a signal-catching function,
with the exception that when a signal interrupts an unsafe function or
function-like macro, or equivalent (such as the processing equivalent to
<i>exit</i>() performed after a return from the initial call to
<i>main</i>()), and the signal-catching function calls an unsafe function
or function-like macro, the behavior is undefined.</blockquote>
because the former lacks the condition that the signal interrupted an
unsafe function or function-like macro (or equivalent).

Digging into the history, the conflict existed in Issue 6 but only for
signal handlers installed using signal(), not sigaction(), because the
conflicting text was on the signal() page.  Bug
https://austingroupbugs.net/view.php?id=66 (which was applied
in Issue 7 TC1) updated the text and copied it into 2.4.3. (It made no
sense for there to be different signal handler rules depending on which
function installed the handler.)

Rather than fix both copies of the duplicated text, the suggested changes
fix 2.4.3 and replace the corresponding text on the signal() page with text
containing a cross-reference to 2.4.3.

Desired Action: 
On page 519 line 18344 section 2.4.3, change:<blockquote>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 signal interrupted a call
to 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
(that is; a call to an ``unsafe function or function-like macro''), or
equivalent (such as the processing equivalent to <i>exit</i>() performed
after a return from the initial call to <i>main</i>()), and the signal
handler calls an unsafe function or function-like macro.</blockquote>
On page 2060 line 67612 section signal(), after:<blockquote>This
restriction does not apply to POSIX applications, as POSIX.1-2024 requires
<i>raise</i>() to be async-signal-safe (see [xref to
2.4.3]).</blockquote>append a sentence (continuing the CX
shading):<blockquote>This standard also defines the behavior for signal
handlers in various other circumstances under which the ISO C standard
states that the behavior is undefined. See [xref to 2.4.3] for
details.</blockquote>
On page 2060-2061 line 67613-67628 section signal(), delete:<blockquote>If
the process is multi-threaded, or if the process is single-threaded and a
signal handler is executed other than as the result of:

[...]

The signal handler calls any function defined in this standard other than
one of the functions listed in [xref to 2.4].</blockquote>

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2025-02-06 14:34 geoffclare     New Issue                                    
2025-02-06 14:34 geoffclare     Name                      => Geoff Clare     
2025-02-06 14:34 geoffclare     Organization              => The Open Group  
2025-02-06 14:34 geoffclare     Section                   => 2.4.3           
2025-02-06 14:34 geoffclare     Page Number               => 519             
2025-02-06 14:34 geoffclare     Line Number               => 18344           
2025-02-06 14:34 geoffclare     Interp Status             => ---             
======================================================================


  • [1003.1(20... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group

Reply via email to