On Tue, Jul 9, 2024 at 7:56 PM Paul Eggert <egg...@cs.ucla.edu> wrote: > > On 7/9/24 22:03, Eric Blake wrote: > > https://www.austingroupbugs.net/view.php?id=1834#c6830 > > > > The current draft of proposed wording would have the C standard state: > > > > 2 The strnlen function counts not more than n characters (a null > > character and characters that follow it are not counted) in the array > > to which s points. At most the first n characters of s shall be > > accessed by strnlen. > > > > 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.
To play devil's advocate, what if strlen ran in reverse from n-1 to 0? Kinda like what happened with glibc's optimized memcpy using SSE4.2, <https://bugzilla.redhat.com/show_bug.cgi?id=638477> (see comment #31). It seems to me that would be valid since strlen only needs to return count. It does not matter how strlen got there. In fact, the string could be broken into two substrings, and strlen ran on each substring, then the results combined to return count to the caller. > 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. Things played out a little differently with the 638477 bug. Jeff
