This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Implement strlcpy [BZ #178]

On 09/17/2014 04:09 AM, Russ Allbery wrote:
David Miller <> 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

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

                [[#include <string.h>
                #include <stdlib.h>]],
                [[char *a = malloc(6);
                strlcpy(a, "hello", 6);]]
AC_DEFINE(HAVE_STRLCPY, 1, [Define if strlcpy is available (most BSDs.)])],

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]