This is the mail archive of the
mailing list for the glibc project.
Re: Wish for 2002 ...
> From: email@example.com (Thomas Bushnell, BSG)
> Date: 10 Jan 2002 23:29:05 -0800
> Paul Eggert <firstname.lastname@example.org> writes:
> > I sense that your intuition tells you that adding strlcpy/strlcat to
> > glibc will lessen the overall work required for the GNU project. My
> > intuition tells me just the opposite.
> I could see a case being made that it would make almost no
> difference. But how does it make it harder?
Because it will encourage use of strlcpy/strlcat, and that will make
application code harder to read and to maintain. That would be a
real, ongoing, and growing cost.
> One way or the other, the function is going to be part of
> the GNU Project, and it's going to have to be maintained.
It can be maintained by the individuals who insist on using
strlcpy/strlcat despite their technical drawbacks. They are certainly
free to do things like that, but we are under no obligation to support
them in misguided efforts. On the contrary: it will be more helpful
in the long run if we can persuade them to use better solutions.
(I realize the OpenSSH developers' minds are made up, but that's OK --
they already port to glibc with no problem, so this is not an
important technical issue for them.)
> From: Damien Miller <email@example.com>
> Date: 12 Jan 2002 00:51:51 +1100
> Having [strlcat] in glibc would also encourage new software to use it.
That is one of the strongest arguments against including strlcat in
glibc. Use of these functions is almost invariably a sign of weak
code. They should not be used in new software.
I continue to think this is the bottom line in this dispute:
should glibc _promote_ the use of these controversial functions?