Re: Wish for 2002 ...

[Paul Eggert <eggert at twinsun dot com>]

> From: tb@becket.net (Thomas Bushnell, BSG)
> Date: 10 Jan 2002 21:46:29 -0800

> > glibc exists for many reasons.  "Optimality" is one of them, but it is
> > not the only one.  It is not even the most important one.
> 
> One of them was once, at least, to implement the functions in use on
> BSD and SysV systems.

It was never glibc's goal to implement every function available on
every BSD and SysV system.  That would not have been practical, or
even desirable.  Instead, the goal was to support functionality from
much of 4.3BSD.  (SysV is a more complicated issue, one that I don't
think we need to discuss here.)

glibc's support for 4.3BSD was a pragmatic goal, not a fundamental
one: it helped get the GNU project up and running.  But this pragmatic
goal did not apply to later BSD versions.  Other function calls from
post-4.3 BSD are not present in glibc, and I think this is
intentional.

For example, glibc lacks 4.4BSD's setmode function.  There are
stronger arguments for including setmode in glibc than for including
strlcpy/strlcat: setmode is more useful in high-quality code, it has
been around longer, and it is harder to implement.  And yet, despite
these stronger supporting arguments, it is still absent from glibc.  I
can see a couple of good reasons why.  First, if setmode is ever
standardized, it may well have semantics that differ from 4.4BSD.
Second, setmode is not essential, as it can be implemented in user
code.  Both of these reasons apply to strlcpy/strlcat too.

Since full compatibility with more recent BSD variants is not
essential or even necessarily desirable for glibc, glibc is not
required to support recent BSD functions that are nonessential or (in
the case of strlcpy/strlcat) arguably counterproductive.


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.