This is the mail archive of the libc-alpha@sources.redhat.com 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: [open-source] Re: Wish for 2002



So suppose that two different programs in common use on my computer
use a function.  Doesn't really matter which function, but let's agree
that it's a function that is rarely if ever wisely used by a
programmer.  It's in the standard library on some other systems, and
there are even misguided people advising other people to use the
function.

Linus says we shouldn't add the function, because adding such
functions to libc increases its memory footprint.  This has two
effects:
1) more core is spent holding glibc
2) glibc gets fragmented resulting in slower performance for all
   programs

I doubt the extent to which (2) is a problem.  If it becomes a real
problem, then the solution is obviously to order the functions in
glibc carefully, so that all the functions not likely to be used in
any given program land all in a few pages, reducing the fragmentation
problem.

(1) seems to be a problem; hey "keep the library small" seems to be
important.  Except that the cost of (1) is that every program that use
the function in question must have its own implementation.  That
imposes three costs:

a) Each program needs to have and maintain its own implementation;
b) If the function is similar to other well optimized glibc functions,
   then the benefits of such optimizations are lost;
c) Since *two* programs on my computer use the function, it now takes
   up *double* the space it would take up if it were used in the
   library.

The function may be rarely if every wisely used, which is an excellent
argument for attaching a warning to its use (as done for several
functions in glibc).

So, the question is:

Under what circumstances should a function be added to glibc?

The answer used to be:

glibc should contain at the very least "all" the functions used in the
C libraries of other systems.  It's *not* the "Linux" C library, it's
the GNU C Library, which like GNU software in general, is intended for
portability across a wide variety of systems.  And like GNU software
in general, it should aspire to being *better* than the alternatives.

Thomas


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