This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Wish for 2002 ...

> From: (Thomas Bushnell, BSG)
> Date: 10 Jan 2002 23:29:05 -0800
> Paul Eggert <> 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 <>
> 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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]