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 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


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