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: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 3 Nov 2015 11:15:50 -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>
On Mon, Nov 02, 2015 at 02:34:14PM +0100, Florian Weimer wrote:
> On 10/29/2015 10:50 PM, Paul Eggert wrote:
> > I'd rather we didn't add strlcpy to glibc, for reasons already
> > discussed. If consensus goes against me, the patch still needs some
> > work. I don't recall the details of our previous discussion; at the risk
> > of reraising old issues here are some comments:
> >
> > * If strlen(SRC) < DESTLEN, the documentation should clearly state that
> > the contents of the bytes DEST[strlen(SRC) + 1] through DEST[DESTLEN -
> > 1] are preserved. The current documentation can be plausibly read that
> > way, but it's not explicit.
>
> I don't want to give any guarantees other implementations do not provide.
I agree strongly with this principle, but I do think this is
guaranteed by other implementations, in terms of both actual behavior
and the implicit requirement not to clobber memory the function is not
specified to clobber. If there's doubt we should clarify with the
authors of the original. Am I correct in thinking the OpenBSD version
is the original?
> > * strlcpy's implementation should use memmove instead of memcpy. The
> > main motivations for strlcpy are safety and consistency and avoiding
> > errors. memmove obviously supports these goals better than memcpy
> > does. Efficiency is not a major concern with strlcpy (if it were,
> > strlcpy wouldn't be O(strlen(SRC))).
>
> The original OpenBSD implementation does not handle all overlapping
> buffers in the same way memmove would. Most BSDs now specify the
> restrict qualify in the function prototype and documentation.
>
> The existing *_chk functions do not check for overlapping inputs, and
> they even have restrict pointer arguments, so such checks could be
> futile anyway. If we want to change this approach, I think this should
> be a separate discussion. (Right now, there is memstomp for this.)
Agreed, but I just want to add that I don't think the restrict
qualifier precludes testing for overlap. None of the requirements
imposed by restrict apply unless you actually access an object based
on the restrict-qualified pointer(s). So any tests that take place
before dereferencing should be safe against being optimized out.
Rich