Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: Re: Shared Lib Question (ISC)
Message-ID: <174@titccy.cc.titech.ac.jp>
Date: 10 May 91 07:19:26 GMT
References: <276@rwing.UUCP> <162@titccy.cc.titech.ac.jp> <19252@rpp386.cactus.org>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 32

In article <19252@rpp386.cactus.org>
	jfh@rpp386.cactus.org (John F Haugh II) writes:

>The trouble (as I see it) is that the C libraries were not
>designed well from the start.  The notion that there should
>never be global variables with all manner of hidden side
>effects was beaten into my brain as a CS undergrad.  Not to
>slight Ritchie, et al, but they appear not to have suffered
>the same violent abuse at the hands of their instructors ...

Consider an OS. It contains process private global variables, such as uid,
which has global hidden side effects.

As you know, UNIX libraries are well desined so that there is no distiction
between library calls and pure system calls.

A pure system call, one day, may be implemented as a complex library call
the other day.

Thus, it is natural that a library call have its own state, like a stdio
library.

>Were the code in the C library pure, shared libraries would
>be extremely simple to implement.  Data, which isn't sharable,
>is the worst of the flies in the ointment.

It is absurd to make C libraries complex only for the simple implementation
of shared library.

BTW, data for indirect jump to library routines is, anyway, not sharable.

						Masataka Ohta