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]

Fwd: The semantics of strlcpy and strlcat


Accidental off-list reply, sorry.


---------- Forwarded message ----------
From: Zack Weinberg <zackw@panix.com>
Date: Sat, Jan 23, 2016 at 12:43 PM
Subject: Re: The semantics of strlcpy and strlcat
To: Paul Eggert <eggert@cs.ucla.edu>


On Fri, Jan 22, 2016 at 3:43 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 01/22/2016 12:12 PM, Zack Weinberg wrote:
>> It is my contention that glibc must adopt behavior which is unanimous
>> among the various _replacement_ implementations of these functions---that
>> is, implementations shipped by applications for use when the system does not
>> provide the function. System-provided implementations are only to be
>> considered when there is no unanimity among replacement implementations.
>
> This contention is at odds with how apps are configured. Typically, apps use
> the system-provided strlcpy/strlcat when available, and use their private
> implementations otherwise. So, on NetBSD these apps use NetBSD
> strlcpy/strlcat, and they're therefore working fine with an implementation
> that rejects size-zero copies to and from NULL. If anything, the NetBSD
> implementation should trump the apps' implementations, since it's what's the
> apps use on NetBSD.

I might have agreed with this analysis if we were having this
conversation shortly after strlcpy had been invented (circa 1998, it
appears).  Now, though, we have a huge installed base _on glibc-based
systems_ of programs using their fallback implementations that don't
dereference the destination buffer pointer when the destination size
is zero; adding strlcpy/strlcat to glibc with different semantics is
effectively a breaking ABI change for those programs.  I do not trust
the installed base of NetBSD systems to be large enough to have
flushed out any programs that rely on the no-dereference semantics.

Moreover, to the extent that we have a choice, I strongly prefer the
choice that avoids defining a corner case to be UB, for the
philosophical reasons stated in my original message in this thread.

(And I must reiterate that this is not just about the destination
pointer being NULL.  "Does not dereference" is a stronger condition
than "allows NULL.")

>> I do not understand what you are trying to say here.  I can only see
>> two possible interpretations: given a call strlcat(d, s, n),
>>
>>   * The addition `n + strlen(s)` might overflow the range representable
>>     by size_t.
>
> Yes, that's the intended interpretation.

OK, I agree that it would be good to trap that condition (I would
suggest returning SIZE_MAX on overflow) but that has nothing to do
with the contents of the buffer; an overflow can just as easily occur
for `1 + strlen(s)`.

zw


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