This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]
- From: Alexander Cherepanov <ch3root at openwall dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 5 Jan 2016 05:27:16 +0300
- Subject: Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]
- Authentication-results: sourceware.org; auth=none
- References: <5682DD7E dot 6000301 at redhat dot com> <56839678 dot 8040304 at cs dot ucla dot edu> <568ADC5F dot 5010608 at redhat dot com> <568B0824 dot 6000101 at openwall dot com> <568B13CE dot 3060507 at cs dot ucla dot edu>
On 2016-01-05 03:52, Paul Eggert wrote:
On 01/04/2016 04:02 PM, Alexander Cherepanov wrote:
The description of snprintf in C11 doesn't mention size of the
destination array or talk about any connection between n and s at all,
True, but the POSIX description for snprintf (s, n, ...) has the
additional restriction that n must be the size of the buffer referred to
by s, so POSIX implementations of snprintf can assume that s's size is n
and that the destination array does not overlap any of the sources,
regardless of which parts of the destination are written to.
Are you seriously arguing for glibc not to comply with C11? I probably
miss something about glibc...
OTOH [1] states (Excluding dprintf()): "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-2008 defers to the ISO C standard."
[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/snprintf.html
So, you just found a bug in POSIX. Cool!
Then, descriptions (e.g. [2], [3]) of strlcpy and strlcat refer to C9X
or BSD, not to POSIX. So it's not relevant to the current discussion.
[2] https://www.sudo.ws/todd/papers/strlcpy.html
[3]
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/strlcat.3?query=strlcpy&sec=3
Finally, when the standard talks about objects that copying takes place
between, it doesn't necessarily mean whole original objects. In most
cases their sizes are not known at all. Well, do you think the fact that
@var{to} and @var{from} overlap makes the code:
char s[10] = "abc";
strncat(s, s, 2);
is invalid even though there is no overlapping copying?
--
Alexander Cherepanov