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: Alexander Cherepanov <ch3root at openwall dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 11 Jan 2016 02:29:31 +0300
- 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> <569038BB dot 7050101 at cs dot ucla dot edu>
On 2016-01-09 01:31, Paul Eggert wrote:
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!),
Hm, strlcpy doesn't really differ from an ordinary strlen in this
regard, so I'm not sure to which degree this is evidence against strlcpy
and to which -- against C strings. Perhaps the problem is that all
official examples of strlcpy are of the form "len = strlcpy(...); if
(len >= size) ..." (that is, no "+ 1" here) while for strlen it's quite
common to write "strlen(...) + 1" (that is, adding one right away).
OTOH such a bug with strlen will lead to buffer overflow instead of
truncation. Not really better:-)
its use case is
already well-addressed by the standard API, and portable programs can
(and already do) use something like the following instead.
This could be an argument against addition of strlcpy in general but
specifically for size=0 it seems to confirm importance of the case:-)
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.
Ok, I misunderstood you.
There are sound software-engineering
reasons for insisting that strlcpy be no less reliable and strict than
strlcat,
Given that strlcat 'dest' argument is often prepared by strlcpy I can
see why strlcpy should be not less reliable than strlcat -- there is
just no reason for strlcat to be more robust than strclpy. But why
strlcpy should be no less strict than strlcat?
and for the two functions to follow the same rules.
The functions are different and it's not entirely clear what you mean
exactly.
One possible guiding principle: strlcat should be able to accept
anything after strlcpy. This would mean that it should accept size=0 if
strlcpy does it but not other non-null-terminated dest arrays.
But taken in isolation strlcat for non-null-terminated dest arrays
(including the case of size=0) is somewhat different from strlcpy for
size=0: the result of strlcpy with size=0 is the amount of memory you
have to allocate for a successful retry, the result of strlcat with a
non-null-terminated dest array is mostly useless because the length of
dest is still unknown.
OTOH strlcat is sometimes used after snprintf (~40 cases in OpenBSD
sources). Does it mean that strlcat should be as reliable and strict as
snprintf?
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.
I guess this implies that it should be documented in the sources which
guarantees the implementation provides in addition to those in the
user-facing manual so that it's not broken later by someone looking only
at the manual.
--
Alexander Cherepanov