This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Alexander Cherepanov <ch3root at openwall dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 8 Jan 2016 14:31:23 -0800
- Subject: Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]
- Authentication-results: sourceware.org; auth=none
- References: <5682DD7E dot 6000301 at redhat dot com> <56839678 dot 8040304 at cs dot ucla dot edu> <568ADC5F dot 5010608 at redhat dot com> <568B1587 dot 4030905 at cs dot ucla dot edu> <568C08E1 dot 2010604 at redhat dot com> <568C3ED3 dot 1090405 at cs dot ucla dot edu> <56900DAF dot 60602 at openwall dot com>
Alexander Cherepanov wrote:
it's handy
No, because even if that example's silent-truncation bug were fixed (which is
yet another bit of evidence against strlcpy!), its use case is already
well-addressed by the standard API, and portable programs can (and already do)
use something like the following instead.
void
cpy_with_growing (char **dest, char const *src, size_t *size)
{
size_t s = strlen (src) + 1;
if (*size <= s)
{
free (*dest);
size_t doubled = 2 * *size;
*size = s <= doubled ? doubled : s;
*dest = xmalloc (*size);
}
memcpy (*dest, src, s);
}
you can catch size=0 with strlcat even if strlcpy accepts size=0 without triggering any protections.
No, because often only strlcpy is executed, with strlcat used only in relatively
unusual circumstances. There are sound software-engineering reasons for
insisting that strlcpy be no less reliable and strict than strlcat, and for the
two functions to follow the same rules.
be conservative in what you document, be liberal in what you implement.
Yes, that's a goal of my most recently-proposed documentation. Again, I don't
think we should add strlcpy+strlcat to glibc; but if we do add them, we should
document them conservatively.