strlcpy() and strlcat() once again

[MichaÅ GÃrny <gentoo at mgorny dot alt dot pl>]

Hello,

I would like to suggest taking an another look at the topic of including
strlcpy() and strlcat() in glibc.

AFAIK, the major reason for past rejections of these functions is that
they might endorse 'poor programming practices'. Whether or not I agree
with that is unimportant here.

It must be accepted that if you thought you can stop projects from
proliferating these functions by simply denying their existence, you
were terribly wrong. The facts show that more and more packages use
them, including packages originating from Linux itself (which I consider
a major glibc consumer) such as ALSA.

Thus, the only result of rejecting these functions is that each user
of glibc has more than 100 static copies of strlcpy() and strlcat()
in the user's system. The number I give is probably an underestimation.
I did a quick zgrep and bzgrep on my distfiles directory; after dropping
duplicates, I get:

60 gz-strlcpy
87 bz2-strlcpy
147 total

Not to mention that each of these source packages might create any
number of executables, each one bearing another copy of strlcpy() and
strlcat().

glibc's job is to prevent proliferation of arbitrary implementations of
low-level well-defined functions. The best and essentially only method
of preventing packages from compiling their own strlcpy() and strlcat()
functions would be for glibc to include these functions. Please
reconsider this issue and provide a way to avoid having packages include
their own versions of the strl functions.

Thanks in advance for any help.

-- 
Best regards,
MichaÅ GÃrny