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

[Tolga Dalman <tolga dot dalman at googlemail dot com>]

On 11/08/2015 02:07 AM, Rich Felker wrote:
> On Sun, Nov 08, 2015 at 01:48:38AM +0100, Tolga Dalman wrote:
>> As a mere user, I have never needed strlcpy myself. Given that this
>> function is quite easy to realize, I see no reason to include such
>> a function in glibc.
> 
> Unfortunately that's NOT a given. Most reimplementations from scratch
> have at least one serious corner-case bug. And if you have more than
> one in the same program (e.g. multiple shared libraries that each
> implement their own) they all end up using the copy from whichever
> library was linked first, which might have a corner-case bug that
> affects the other users. This is the main compelling security reason
> for having the functions in libc: to get programs/libraries to stop
> providing their own likely-buggy versions.

It is difficult to discuss about this topic in an abstract manner.
I believe that most uses of strlcpy and strlcat are really unjustified
as they could be easily replaced by strncat/strcpy. As I wrote above,
this is just my personal (perhaps naÃve) view.
Can you send me a list of concrete examples where the specific features
of these functions are necessary (e.g., the memory beyond \0 must not
be written)?
If performance is really the reason, I would like to review some
benchmarks before continuing the discussion at that point.

>> Also, I see only little value in improving the
>> portability with BSDs beyond POSIX, really. Thus, the real value of
>> adding this function appears to be convenience reasons. Anyway, this
>> is my personal view. As Rich stated, the arguments have been on the
>> table several times and it is not my intent to restart the discussion.
>>
>> Instead, my proposal is to add this function to glibc, but in a separate library.
> 
> That is utterly useless and much more costly. Each additional library
> linked adds at least 4k of (non-shareable) memory usage to a process
> and increases the start time by tens or hundreds of microseconds. But
> most importantlu, if they're not available in the default link,
> configure scripts will never find/use them, and they'll just end up
> enabling their own replacements.
> 
> Anyway, in general, if adding a function to glibc is a bad idea,
> adding it in its own separate .so file shipped with glibc is an even
> worse idea. There are no advantages and lots of disadvantages.

I am not talking about a libstrlcpy but instead something like libbsd_ext.
Again, we are talking quite abstractly about applications. Do you have
a list of open source applications that use strlcpy or strlcat?

Anyway, I note that you are quick to argue against my idea. What is your
proposal to resolve the issue in glibc?