This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Implement strlcpy [BZ #178]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Russ Allbery <eagle at eyrie dot org>, David Miller <davem at davemloft dot net>
- Cc: eggert at cs dot ucla dot edu, libc-alpha at sourceware dot org
- Date: Wed, 17 Sep 2014 14:53:13 +0200
- Subject: Re: [PATCH] Implement strlcpy [BZ #178]
- Authentication-results: sourceware.org; auth=none
- References: <54171793 dot 4080900 at cs dot ucla dot edu> <20140915 dot 125633 dot 1631061894621241191 dot davem at davemloft dot net> <54172A83 dot 6050504 at redhat dot com> <20140915 dot 145312 dot 1697096558356222023 dot davem at davemloft dot net> <87k353c80j dot fsf at hope dot eyrie dot org>
On 09/17/2014 04:09 AM, Russ Allbery wrote:
David Miller <davem@davemloft.net> writes:
I think the fact that there are 60 such cases supports my arguments even
more strongly, because that is how many strlcpy users are even less
likely to ever change if glibc supports strlcpy too.
I'm pretty sure I have a package for which I'm upstream in Fedora, which
means I represent one of those uses. (And there's at least INN, for which
I was responsible for introducing strlcpy.) Based on the previous
conversation, I'll probably eventually end up removing strlcpy entirely in
favor of other techniques, but all my packages that currently use strlcpy
only optionally compile it if it's not in libc. If it's in libc, the
system version is preferred, since it's presumably more optimized and
possibly safer.
I suspect this is not uncommon among strlcpy users. (Basically, using
AC_REPLACE_FUNCS.)
Yes, that's what I meant with that anything we do outside glibc would be
a distribution-specific effort. It's not just AC_REPLACE_FUNCS,
autoconf checks like this one
AC_LINK_IFELSE(
[AC_LANG_PROGRAM(
[[#include <string.h>
#include <stdlib.h>]],
[[char *a = malloc(6);
strlcpy(a, "hello", 6);]]
)],
[AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_STRLCPY, 1, [Define if strlcpy is available
(most BSDs.)])],
[AC_MSG_RESULT(no)]
)
are used as well. In theory, we could overlay <string.h> from libbsd on
top of the glibc headers, but really want to do this only for a libbsd
subset (because some of the things in libbsd are extremely gross). This
would avoid the need to change the autoconf detection logic in all
packages, but it's still distribution-specific work, just less of it.
On the other hand, it's just pie-in-the-sky because such build hacks are
unlikely to be acceptable to Fedora and Debian, and perhaps rightly so.
Having these commonly used functions inside glibc proper would make
things much easier.
--
Florian Weimer / Red Hat Product Security