This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Fwd: The semantics of strlcpy and strlcat
- From: Zack Weinberg <zackw at panix dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 23 Jan 2016 12:43:49 -0500
- Subject: Fwd: The semantics of strlcpy and strlcat
- Authentication-results: sourceware.org; auth=none
- References: <CAKCAbMhfFmfdrVB7_FovQmfrbAAXjKmis3-JWnD1qDEODi_gQg at mail dot gmail dot com> <56A177CF dot 1010308 at cs dot ucla dot edu> <CAKCAbMioSjaQFVBM9+ScsaEaH=xRad6L76Bx8h-gfNuua=_QAQ at mail dot gmail dot com> <56A29458 dot 4020501 at cs dot ucla dot edu> <CAKCAbMjSzPHh257ArT8o6Rk-j_FNJQn0AAHK2+X3xO2j+646MA at mail dot gmail dot com>
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