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

[David Miller <davem at davemloft dot net>]

From: Florian Weimer <fweimer@redhat.com>
Date: Mon, 15 Sep 2014 20:05:55 +0200

> On 09/15/2014 06:56 PM, David Miller wrote:
>>> But really, it'd be better to keep leaving it out.  It's just a mess.
>> 
>> This is really confusing.
>> 
>> If glibc never had strlcpy before, it's an oxymoron to say it shouldn't
>> be used for new code because that's the only possible usage of it.
>> 
>> If people are just going to start using the glibc copy when available
>> instead of their own home-grown tree local implementation, which seems
>> to be the only remaining "suggested" usage, I say that's bogus too.
>> 
>> So we're providing an interface for people using strlcpy, but at the
>> same time we don't want people to use strlcpy and rather have them
>> use "something else."
>> 
>> Our actions are going to encourage them to continue using strlcpy.
> 
> We could point out that using strlcpy with statically sized buffers is
> against the GNU Coding Standards, which recommend dynamic, on-demand
> buffer allocation.
> 
> Here's some more background why I'm proposing this.  Fedora has over 60
> source packages which compile to binary packages which define strlcpy or
> strlcat.  Many of these packages will not go away, ever.  Only a subset
> of the software has a strong (Open)BSD affinity.

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 not really strongly apposed to adding strlcpy to glibc.  But we
should be completely honest about why we are doing this, what the
effects on existing strlcpy users actually is, and what we should
genuinely recommend to people writing new code.