The following issue has been SUBMITTED.
======================================================================
https://www.austingroupbugs.net/view.php?id=1726
======================================================================
Reported By: Florian Weimer
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 1726
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Florian Weimer
Organization: Red Hat
User Reference: swbz#178
Section: strlcat
Page Number: unknown
Line Number: unknown
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2023-05-10 06:29 UTC
Last Modified: 2023-05-10 06:29 UTC
======================================================================
Summary: strlcat specification is ambiguous regarding return
value
Description:
A glibc developer tried to implement a hand-written assembler version of
strlcat based on the POSIX specification and the OpenBSD manual page, and
they were surprised when our test suite flagged their implementation as
broken.
Effectively, we test that
strlcat (buf, src, 0)
is equivalent to:
strlen (src)
But the specification can be easily read as saying that it should be
strlen (buf) + strlen (src)
i.e., that it does not matter whether the original contents of the
destination buffer contains null bytes or not.
Desired Action:
Existing implementations use the buffer size as a bound for the length of
the original buffer contents. This is documented fairly explicitly in the
Solaris manual page:
“The function returns min{dstsize, strlen(dst)} + strlen(src).”
<https://docs.oracle.com/cd/E36784_01/html/E36874/strlcat-3c.html>
I think the POSIX version should be change so that it is clear that it does
not mandate a different behavior. Either it should say explicitly that the
return value of strlcat is
strnlen(dst, dstsize) + strlen(src)
or that strlcat behavior is undefined if there is no null byte among the
first dstsize bytes in the buffer at buf.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2023-05-10 06:29 Florian Weimer New Issue
2023-05-10 06:29 Florian Weimer Name => Florian Weimer
2023-05-10 06:29 Florian Weimer Organization => Red Hat
2023-05-10 06:29 Florian Weimer User Reference => swbz#178
2023-05-10 06:29 Florian Weimer Section => strlcat
2023-05-10 06:29 Florian Weimer Page Number => unknown
2023-05-10 06:29 Florian Weimer Line Number => unknown
======================================================================
