This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Implement strlcpy [BZ #178]
- From: Russ Allbery <eagle at eyrie dot org>
- To: David Miller <davem at davemloft dot net>
- Cc: fweimer at redhat dot com, eggert at cs dot ucla dot edu, libc-alpha at sourceware dot org
- Date: Tue, 16 Sep 2014 19:09:48 -0700
- 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>
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.)
--
Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>