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

[Rich Felker <dalias at libc dot org>]

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.

> 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.

Rich