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

[Florian Weimer <fweimer at redhat dot com>]

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