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: Tue, 5 Jan 2016 22:14:48 +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> <568B0824 dot 6000101 at openwall dot com> <568B13CE dot 3060507 at cs dot ucla dot edu> <568B2A04 dot 9050904 at openwall dot com> <568B6B91 dot 5080904 at cs dot ucla dot edu>
On 2016-01-05 10:06, Paul Eggert wrote:
Are you seriously arguing for glibc not to comply with C11?
Naaah.And on second thought, my comment was based on a backwards
interpretation of the POSIX spec: that spec places extra constraints on
the implementation not on the application. So please forget my mistaken
comment about POSIX snprintf.
Sorry, I don't understand what you mean. Your first reading of POSIX
seems quite reasonable to me. And that reading conflicts with C11 so I
reported it in http://austingroupbugs.net/view.php?id=1020 .
descriptions (e.g. [2], [3]) of strlcpy and strlcat refer to C9X or BSD,
not to POSIX. So it's not relevant to the current discussion.
Yes and no. I think Florian is arguing that strlcpy should act like
snprintf, and so in that sense it's relevant. However, I agree with you
that snprintf is not an exact analog and is not a good precedent for
strlcpy.
It's not just Florian arguing about snprintf, it's the original article
about strlcpy/strlcat referring to snprintf and OpenBSD man page
unambiguously stating:
| Besides quibbles over the return type (size_t versus int) and signal
| handler safety (snprintf(3) is not entirely safe on some systems),
| the following two are equivalent:
|
| n = strlcpy(dst, src, len);
| n = snprintf(dst, len, "%s", src);
What I meant in my previous email is that these descriptions referred to
C9X and BSD flavors of snprintf, not to the POSIX one. But now that we
are agree to ignore POSIX for a moment, this detail is not important.
do you think the fact that @var{to} and @var{from}
overlap makes the code:
char s[10] = "abc";
strncat(s, s, 2);
is invalid even though there is no overlapping copying?
I don't think strncat is an exact analog for strlcat either. That is,
although I agree that the strncat example has well-defined behavior in
C11, this is not precedent for strlcat, any more than snprintf would be.
They're just different functions, that's all.
For example, it'd be reasonable for strlcpy to verify that every byte in
the destination array is writeable. That could help catch bugs in
programs. The spec should not disallow such an implementation.
Ok, I guess it boils down to the question which sources are considers
authoritative for describing strlcpy/strlcat? Is OpenBSD man page included?
--
Alexander Cherepanov