Re: [libc-alpha] Re: [open-source] Re: Wish for 2002

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On Mon, 7 Jan 2002, Russ Allbery wrote:

> Date: Mon, 07 Jan 2002 18:36:32 -0800
> From: Russ Allbery <rra@stanford.edu>
> To: libc-alpha@sources.redhat.com, open-source@csl.sri.com
> Subject: [libc-alpha] Re: [open-source] Re: Wish for 2002
> 
> Thomas Bushnell, BSG <tb@becket.net> writes:
> > Russ Allbery <rra@stanford.edu> writes:
> 
> >> strlcpy is useful in situations where you want to just patch the
> >> problem and don't want to deep analysis of the code to figure out why a
> >> buffer is being used.  This is an appropriate approach for a porter to
> >> take.  It's not clear to me that this is an appropriate approach for a
> >> maintainer to take.
> 
> > Sure, but libc should be useful for porters too.
> 
> Yes, on that I generally agree, and I could see some utility in having
> those functions available to people porting software to Linux, similarly
> to how having them available in the BSD libc helps people porting software
> to BSD.

They are available in BSD because that's where they originated. The
maintainers of some BSD distribution can take some program which they
intend to add to the distribution, go through it and fix buffer
overflow problems using these functions, without necessarily
understanding the program, or following up on any deeper implications
of the use of fixed length buffers for strings. That program is then a BSD
program, its portability is irrelevant since it has been swallowed up
into the CVS of that distribution. This is not how GNU programs are
developed at all; GNU programs are still developed with portability
in mind. Not just portabiilty to standard interfaces, but to
implementations and old installations.

Sure it's useful to porters to have as many foreign functions available
in a library. By that logic, glibc should have all of Win32 in it.
Writing a five line implementation of strlcpy to make a program work is
nothing compared to, say, the work required to hack up an emulation of
the various Reg*() functions to access the registry.  Or should there
be a threading library compatible with Solaris threads so that people
don't have to fix their code to use POSIX?

Are the porters whore are moving code from Sun or BSD to Linux really
in desperate need for help from glibc?

The people who are primarily responsible for portability are the ones
who write the application code in the first place; you can't expect
others, such as the glibc developers, to pick up the slack for lazy
slobs who write code that is unnecessarily nonportable, or that even
has no layering to anticipate the need to port.

By the way, I'm not opposed to the strl*() functions being added;
I only don't buy the arguments in favor of doing it which have been
presented so far. There have basically been two arguments:

1. Vendors W, X and Y have these functions, so Z should be pressured into
having them too. Geez, isn't that why we have working groups of people
to develop these things called standards? The people pushing these
functions should commit themselves to something solid, like
participating in a standardization group, rather than pestering the
mailing lists where nothing will get accomplished.

2. There are some technical claims we can make about the usefulness of
these functions. If programmers can find these functions in their local
programming manual pages, they will see the light and start writing
much better programs that avoid a class of errors. Well, why can't
these programmers see the light on their own? What does it take to
figure out that maybe after cutting and pasting some code several times
that cleans up after strncpy, maybe it's time to write a simple-to-use
function that properly null terminates, and reports truncation?
Geez, should glibc have a networking function that contacts consumer
retail websites and orders clean diapers and baby formula for the
developer?