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

On Sat, Jan 12, 2002 at 04:36:45PM -0800, Russ Allbery wrote:
> > and developers little fallback collection of functions for use together
> > with autoconf.
> Seems to me that they only pay this cost if they choose to use strlcpy.

But if they already choosed this bsd function on their BSD system, why
not let glibc provide that function so they can use it on their GNU

> If you agree that they shouldn't be doing that in the first place, why do
> you want to help make it less costly to make a poor decision?

Add a compile-time warning too and document why glibc warns the people
who use this function. Glibc then tells it's a poor decision, without
including it those people are never told it's a poor decision.

To summerize the argument for including them:
* Those functions are commonly used and exist on BSD and some other
systems. It's the job of glibc to provide those functions for the sake
of other people who want to use it. It was a goal of glibc to
implement the functions from BSD.
* The people who use strlc*() are told with a warning that it's bad to
use those function. So an inexperienced programmer probably isn't
going to use those functions. People who really think the function is
good will use it anyway. IMHO we should respect the opinion of those
people and include the functions in glibc.
* There are a lot of functions in glibc which are broken, some of them
are even more broken then strlc*() and they even don't have a warning
* Glibc gets bigger, but the binaries using strlc*() get smaller and
probably use a better optimized version of strlc*(). I think it will
be faster if glibc provides those functions, but certainly it won't be
* Not including them won't make people use dynamic allocation. There
are enough fools who don't have strlc*() and use static allocations in
places where it's unportable and you should use dynamic
allocation. Using fixed-size buffers for paths for example, as 
PATH_MAX is optional (look in your version of POSIX if you don't
believe me) and systems may have no limit on the path size. GNU/Hurd
is such a system for example.

So why aren't those functions in glibc yet?

Jeroen Dekkers
Jabber supporter - Jabber ID:
Debian GNU supporter -
IRC: jeroen@openprojects

Attachment: msg00175/pgp00000.pgp
Description: PGP signature

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