This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Implement strlcpy [BZ #178]
- From: David Miller <davem at davemloft dot net>
- To: eggert at cs dot ucla dot edu
- Cc: fweimer at redhat dot com, libc-alpha at sourceware dot org
- Date: Mon, 15 Sep 2014 12:56:33 -0400 (EDT)
- Subject: Re: [PATCH] Implement strlcpy [BZ #178]
- Authentication-results: sourceware.org; auth=none
- References: <54170B62 dot 90900 at cs dot ucla dot edu> <54171592 dot 3040609 at redhat dot com> <54171793 dot 4080900 at cs dot ucla dot edu>
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.