A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1834 
====================================================================== 
Reported By:                Don Cragun
Assigned To:                
====================================================================== 
Project:                    1003.1(2024)/Issue8
Issue ID:                   1834
Category:                   System Interfaces
Type:                       Error
Severity:                   Editorial
Priority:                   normal
Status:                     New
Name:                       Don Cragun 
Organization:                
User Reference:              
Section:                    strlen() & wcslen() 
Page Number:                2147, 2380 
Line Number:                70218-70220, 77131-77134 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2024-06-20 00:26 UTC
Last Modified:              2024-07-10 01:31 UTC
====================================================================== 
Summary:                    strnlen() & wcsnlen() descriptions use of
"terminating" NUL character
====================================================================== 

---------------------------------------------------------------------- 
 (0006831) eblake (manager) - 2024-07-10 01:31
 https://www.austingroupbugs.net/view.php?id=1834#c6831 
---------------------------------------------------------------------- 
At https://lists.gnu.org/archive/html/bug-gnulib/2024-07/msg00094.html,
Paul Eggert argues:

<blockquote>
> at which point, strnlen("", SIZE_MAX)_is_  allowed to_access_  beyond
> the NUL byte,

No it wouldn't, because strnlen must stop counting at the first null byte.

If this point isn't made clear in the current proposal, it should be made
clear. Lots of user code relies on strnlen doing the right thing even if
the
string is shorter than n. In practice implementations that screw up in
this
area, and are incompatible with glibc etc., are deemed broken and are
fixed.
The standard should not allow further breakage.
</blockquote>

The proposed wording allows an implementation to access beyond the NUL when
a string is passed in, and Paul is arguing that the standard should be
stricter and stop accessing at the first NUL or at n bytes, whichever is
first (implying a specific linear access pattern, and preventing
optimizations such as dividing the array in two, calculating constrained
lengths on both halves in parallel, and then doing the appropriate math to
return the correct answer even if more bytes than the returned value were
accessed).  That is, Paul wants code like this (present in the wild) to
"work":

      len = strnlen (string, precision <= 0 ? SIZE_MAX : precision); 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2024-06-20 00:26 Don Cragun     New Issue                                    
2024-06-20 00:26 Don Cragun     Name                      => Don Cragun      
2024-06-20 00:26 Don Cragun     Section                   => strlen() & wcslen()
2024-06-20 00:26 Don Cragun     Page Number               => 2147, 2380      
2024-06-20 00:26 Don Cragun     Line Number               => 70218-70220,
77131-77134
2024-06-20 00:26 Don Cragun     Interp Status             => ---             
2024-06-20 00:38 Don Cragun     Description Updated                          
2024-06-20 00:38 Don Cragun     Desired Action Updated                       
2024-06-20 11:15 geoffclare     Note Added: 0006820                          
2024-06-20 14:30 Don Cragun     Note Added: 0006821                          
2024-06-20 14:32 Don Cragun     Note Edited: 0006821                         
2024-06-20 14:57 geoffclare     Note Added: 0006822                          
2024-06-20 15:33 Don Cragun     Note Added: 0006823                          
2024-06-20 18:22 eblake         Note Added: 0006824                          
2024-06-21 15:24 nick           File Added: n3252b.pdf                       
2024-06-21 15:28 nick           Note Added: 0006830                          
2024-07-10 01:31 eblake         Note Added: 0006831                          
======================================================================


  • [1003.1(2024... 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
    • [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
    • [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