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

[Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>]

On 15-09-2014 13:56, David Miller wrote:
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 15 Sep 2014 09:45:07 -0700
>
>> On 09/15/2014 09:36 AM, Florian Weimer wrote:
>>> How is it incompatible with the OpenBSD implementation?
>>>
>> As Rich Felker mentioned, OpenBSD strlcpy always returns the length of
>> the source, regardless of what was stored.
>>
>>> The original documentation for strncpy already called it “rarely
>>> useful”, otherwise I wouldn't have used this phrasing.
>>>
>> strlcpy is rarely useful as well.  I agree with Rich that if we
>> document strlcpy, we should say that it's not recommended for new
>> code.  We should also mention the above problem, which unfortunately
>> is an all-too-common misunderstanding of how strlcpy works.
>>
>> 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.
>
I also don't seem useful to add these interfaces to GLIBC. From last discussion, the
examples discussed showed no advantage using them and in some cases they in fact
clobbered real issues by the (wrong) assumption that truncate is better than buffer
overrun.

The only reasonable suggestion I noted was that since programs uses it, for GLIBC
they tend to use external implementations that may have not correctly implementations.
However this suggestion falls in the logic you just noted: we will provide an interface
that we will suggest to *not* use for security reasons and we will also need to sync
somewhat with other implementation that might be sub-par as well.