Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uakari.primate.wisc.edu!sdd.hp.com!news.cs.indiana.edu!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: Shared Lib Question (ISC)
Message-ID: <14213:May1522:13:2291@kramden.acf.nyu.edu>
Date: 15 May 91 22:13:22 GMT
References: <174@titccy.cc.titech.ac.jp> <19256@rpp386.cactus.org> <7516@segue.segue.com>
Organization: IR
Lines: 40

In article <7516@segue.segue.com> jim@segue.segue.com (Jim Balter) writes:
> So, one can
> implement the C library as a shared library without globals if one is willing
> to claim that the wrappers and the overhead they require isn't part of the
> implementation, but that is stretching it.

Yeah. I've been arguing this with John via e-mail. He keeps repeating
the same old description of how to separate a library into a sharable
part and the part with the global variables. I keep pointing out that
the global variables are still there. We all know how to write a shared
library under the *constraint* of no static data, but the issue here is
whether that is a real constraint---i.e., whether good libraries can use
globals. John keeps ignoring the fact that malloc() does use globals.

C'mon, John, would you just admit that eliminating global variables is
not always a good idea, and that requiring that shared libraries be pure
is a real constraint?

> The obvious other C library routine that requires globals is malloc.
> You could pass it an arena descriptor, but that would require that any library
> routine that ever possibly might be shared and use malloc to be passed the
> descriptor.

Even worse, it requires that any library routine that might *use* one of
those malloc-using routines must also take the pointer. So much for
separating interface from implementation.

Even worse than that, if you want to keep the same interface forever,
you have to predict all libraries that the implementation might use,
directly or indirectly, not just now but in the far future. So much for
finite argument lists. :-(

> It is far better to either keep a register pointing to a global data area,
> as mentioned in my previous note, or to support shared libraries with
> private data, with all the attendant complexity, than to cripple a library
> specification on the basis of a misapplication of CS principles.

Amen.

---Dan