This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4] Implement strlcpy [BZ #178]
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, Florian Weimer <fweimer at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 9 Nov 2015 19:48:42 -0500
- Subject: Re: [PATCH v4] Implement strlcpy [BZ #178]
- Authentication-results: sourceware.org; auth=none
- References: <56326B79 dot 8070804 at redhat dot com> <563294BE dot 9070105 at cs dot ucla dot edu> <56376656 dot 1000600 at redhat dot com> <20151103161550 dot GP8645 at brightrain dot aerifal dot cx> <56393F6F dot 5070301 at cs dot ucla dot edu> <20151104005637 dot GR8645 at brightrain dot aerifal dot cx> <56397280 dot 4000805 at cs dot ucla dot edu> <20151104032321 dot GS8645 at brightrain dot aerifal dot cx> <563A03FD dot 3090106 at redhat dot com> <563A2E72 dot 1000104 at cs dot ucla dot edu>
On 11/04/2015 11:12 AM, Paul Eggert wrote:
> On 11/04/2015 05:11 AM, Florian Weimer wrote:
>> My question is whether we should specify this explicitly for
>> strlcpy. It would give the impression that strlcpy is special in
>> this regard, but it really is not.
> Not a problem, we can add a phrase to avoid giving that impression.
> Something like "Like other string-copying functions but unlike
> strncpy, strlcpy does not modify the part of the destination buffer
> that follows the trailing null byte."
Agreed. The bytes that fall outside of the API contract should be
unmodified.
Doesn't this also have implications in concurrency?
Consider the remainder of @var{to} is being operated upon in parallel.
In the @code{race} section of intro.texi we talk briefly about how
users need to take care with memory buffers passed into functions,
but at the same time we must be exceedingly clear on our end what we
do with those buffers.
Should we forbid reads from parts of @var{to} that are not part of
the API contract?
Likewise there is also an API contract issue with reads of @var{from}
since it forbids concurrent writes to @var{from} because the
implementation has to compute the size of @var{from} by looking for
\0, and thus explicit locking has to be used to protect @var{from}
but not @var{to}, and this can't be easily fixed (follows logically
from the definition of the API).
Thoughts?
Cheers,
Carlos.