A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=708 
====================================================================== 
Reported By:                dalias
Assigned To:                
====================================================================== 
Project:                    1003.1(2013)/Issue7+TC1
Issue ID:                   708
Category:                   System Interfaces
Type:                       Enhancement Request
Severity:                   Editorial
Priority:                   normal
Status:                     New
Name:                       Rich Felker 
Organization:               musl libc 
User Reference:              
Section:                    XSH 2.9.1 Thread-Safety 
Page Number:                unknown 
Line Number:                unknown 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2013-06-07 21:23 UTC
Last Modified:              2023-01-26 12:11 UTC
====================================================================== 
Summary:                    Make mblen, mbtowc, and wctomb thread-safe for
alignment with C11
====================================================================== 

---------------------------------------------------------------------- 
 (0006139) geoffclare (manager) - 2023-01-26 12:11
 https://austingroupbugs.net/view.php?id=708#c6139 
---------------------------------------------------------------------- 
In the January 2023 ballot resolution meeting, WG14 agreed to change (in
C23) the requirement for these functions to avoid data races. At the moment
their plan is to make it implementation-defined, but it is possible someone
may submit a paper for consideration at the next meeting along the lines of
N2281 but with wording changes to address the points raised in the
discussion quoted in https://austingroupbugs.net/view.php?id=708#c5933.

So we should leave this bug open pending a final decision by WG14, but what
goes into C23 will likely only affect what we put in rationale and future
directions in Issue 8, so we could start discussion at least on the
normative text.  I propose the following:

In all of these changes the placeholder <i>XXXX</i> should be replaced with
the name of the function.  Page and line numbers are for Issue 8 draft
2.1.

On page 1274 line 42635 section mblen(), and
page 1285 line 42996 section mbtowc(), and
page 2255 line 72488 section wctomb(), change:<blockquote>The functionality
described on this reference page is aligned with the ISO C standard. Any
conflict between the requirements described here and the ISO C standard is
unintentional. This volume of POSIX.1-202x defers to the ISO C
standard.</blockquote>to:<blockquote>Except for requirements relating to
data races, the functionality described on this reference page is aligned
with the ISO C standard. Any other conflict between the requirements
described here and the ISO C standard is unintentional. This volume of
POSIX.1-202x defers to the ISO C standard for all <i>XXXX</i>()
functionality except in relation to data races.</blockquote>
On page 1274 line 42652 section mblen(), and
page 1285 line 43015 section mbtowc(), and
page 2255 line 72505 section wctomb(), change:<blockquote>[CX]The
<i>XXXX</i>() function need not be
thread-safe.[/CX]</blockquote>to:<blockquote>The <i>XXXX</i>() function
[CX]need not be thread-safe; however, it[/CX] shall avoid data races with
all other functions.</blockquote>
On page 1274 line 42669 section mblen(), and
page 1286 line 43032 section mbtowc(), and
page 2255 line 72522 section wctomb(), change RATIONALE from "None"
to:<blockquote>When the ISO C standard introduced threads in C11, it
required <i>XXXX</i>() to avoid data races (with itself as well as with
other functions), whereas POSIX.1-2008 did not require it to be
thread-safe, and in many implementations it did not avoid data races with
itself and still does not. The ISO C committee intend to change the
requirements in C23, but since POSIX.1 currently refers to C17 it is
necessary for it not to defer to the ISO C standard regarding data races in
order to continue to allow this function not to avoid data races with
itself.</blockquote>
On page 1274 line 42669 section mblen(), and
page 1286 line 43034 section mbtowc(), and
page 2256 line 72524 section wctomb(), change FUTURE DIRECTIONS from "None"
to:<blockquote>It is expected that a change in C23 will allow a future
version of this standard to remove the data race exception from the
statement that it defers to the ISO C standard.</blockquote> 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2013-06-07 21:23 dalias         New Issue                                    
2013-06-07 21:23 dalias         Name                      => Rich Felker     
2013-06-07 21:23 dalias         Organization              => musl libc       
2013-06-07 21:23 dalias         Section                   => XSH 2.9.1
Thread-Safety
2013-06-07 21:23 dalias         Page Number               => unknown         
2013-06-07 21:23 dalias         Line Number               => unknown         
2013-06-08 09:12 geoffclare     Note Added: 0001647                          
2013-06-08 09:13 geoffclare     Tag Attached: C11                            
2013-06-08 12:14 dalias         Note Added: 0001648                          
2013-06-13 15:35 nick           Note Added: 0001651                          
2013-12-03 21:09 torvald        Issue Monitored: torvald                     
2022-08-15 15:11 nick           Note Added: 0005933                          
2023-01-26 12:11 geoffclare     Note Added: 0006139                          
======================================================================


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

Reply via email to