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: Zack Weinberg <zackw at panix dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 8 Jan 2016 23:35:37 +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> <CAKCAbMgbD=QysV2B4cDKau=5YA34XW0423WBq2wtFFyGXifEaQ at mail dot gmail dot com>
On 2016-01-08 22:30, Zack Weinberg wrote:
It remains my opinion that if strl{cpy,cat} are to appear at all in
glibc they should be bug-for-bug compatible with the original OpenBSD
*implementation* (not the ambiguously worded manpage),
OpenBSD strlcat has undefined behavior when dst=NULL and dsize=0. Should
glibc implementation have it too? :-)
Another question: OpenBSD strlcpy/strlcat copy memory in a specific
order with an explicit loop, AFAIK using memcmp doesn't guarantee the
same, should memcmp be ditched here?
Actually, everything is not that bad. Discussion is mostly about
documentation so it should not affect what is used.
But perhaps it's worth stating it explicitly. There are two separate
questions:
1) what should ordinary glibc implementation of strlcpy/strlcat do;
2) which cases should be documented as supported so that all other cases
could be catched by a hardened implementation.
Paraphrasing the famous principle: be conservative in what you document,
be liberal in what you implement.
So, I guess it's better to keep size==0 check in strlcat but document
this case as invalid.
> or else they
> will fail to achieve the desired effect -- applications will continue
> to use their own implementations.
Or worse: they will use glibc implementation and fail in unpredictable ways.
--
Alexander Cherepanov