This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fwd: The semantics of strlcpy and strlcat
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 23 Jan 2016 13:07:02 -0800
- Subject: Re: 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> <CAKCAbMiHRH_upw4aiLx-cS4PyDwMp_mYfwmyKWgynMrNenmQ_g at mail dot gmail dot com>
Zack Weinberg wrote:
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
This is an argument for glibc not adding strlcpy/strlcat. If these programs rely
on corner-case quirks of their substitutes, then any implementation glibc
provides would disagree with some of the replacements and could break the
programs. This is because their replacements do not agree (this is not merely
because of the size-zero buffer issue).
Better to leave sleeping dogs lie, no?
an overflow can just as easily occur
for `1 + strlen(s)`
No it can't. strlcat is weird here because it does not return the size of a
real object as strlen(s) + 1 does; instead, strlcat returns the size of an
*imaginary* object. That is one of the fundamental flaws in strlcat's API, and
any spec for strlcat should address this flaw somehow.