This is the mail archive of the
mailing list for the glibc project.
Re: Wish for 2002
- From: Paul Eggert <eggert at twinsun dot com>
- To: leclerc at austin dot sns dot slb dot com
- Cc: libc-alpha at sources dot redhat dot com, open-source at csl dot sri dot com
- Date: Wed, 2 Jan 2002 16:59:29 -0800 (PST)
- Subject: Re: Wish for 2002
- References: <3C339F99.F1F3B513@austin.sns.slb.com>
> Date: Wed, 02 Jan 2002 18:02:33 -0600
> From: Francois Leclerc <firstname.lastname@example.org>
> One of the impediment is the portability of strlcat and strlcpy in glibc.
This area is controversial. Personally, I avoid strlcat and strlcpy,
as I don't think they add much security in practice, and any minor
advantages they have in that area tend to be outweighed by the fact
that they make code harder to read and to maintain (which introduces
its own set of security problems). I therefore don't recommend their
use in GNU applications, and I discourage requests to use them in GNU
applications that I help maintain.
Some application maintainers disagree with me on this issue, and they
are free to define and use their own versions of these functions.
Portable code must define its own strlcat and strlcpy anyway, as these
functions are not standardized and have different semantics on
different hosts. So portability is not an unassailable argument for
adding them to glibc.
If a standard like POSIX required us to add these functions to glibc,
then of course we would add them (perhaps with advice not to use them :-).