Re: Libification project (SoC)

[Theodore Tso <tytso@mit.edu>]

On Mon, Mar 19, 2007 at 02:43:54AM +0100, Johannes Schindelin wrote:
> >   I was talking about the API. The API has to be designed to be 
> > reentrant. And you get pretty much stuck with the API. And requiring 
> > reentrance isn't that far off once libgit is there, as I tried to point 
> > out; it's not really any obscure requirement.
> 
> - it is easy enough to extend the API later, _retaining_ the small and 
>   beautiful functions.

Um, look at what we had to do with gethostbyname() and
gethostbyname_r().  It wasn't possible to sweep through and fix all of
the programs that used gethostbyname(), despite the fact that if a
program called gethostbyname(), then called library function which
unknowingly to application, could possibly do a DNS or YP lookup (and
whose behavior could change depending on some config file like
/etc/nsswitch.conf), which would blow away the static information.  So
if the application tryied to use the information returned by _its_
call to gethostbyname after calling some other library function, it
could get some completely random hostname that wasn't what it
expected.

Yelch!  And so we have two API's that libc has to support,
gethostbyname(), and gethostbyname_r(), with the ugly _r() suffix, and
which in a sane world most programs should use since otherwise they
can be incredibly fragile unless the _first_ thing they do after
calling gethostbyname is to copy the information to someplace stable,
instead of relying on the static buffer to remain sane.  (And yet they
don't, which means bugs that only show up if optional YP or Hesiod
lookups are enabled, etc.)

Berkely got it horribly wrong when it tried to start with the "small
and beautiful" functions that were non-reentrant, and we've been
paying the price ever since.  Do we really want to support two
versions of the API forever?  Is it really that hard to support a
reentrant API from the beginning?  I'd submit the answer to these two
questions are no, and no, respectively.

						- Ted