This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v4] Implement strlcpy [BZ #178]


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]