Shared Lib Question (ISC)

John F Haugh II jfh at rpp386.cactus.org
Sun May 19 06:26:07 AEST 1991


In article <162950 at felix.UUCP> ka at felix.UUCP (Kenneth Almquist) writes:
>jfh at rpp386.cactus.org (John F Haugh II) writes:
>> Name a single library function which cannot be implemented well
>> without global variables.  Justify your answer.
>
>How about:
>
>1)  getpwent and relatives -- needs global variables to hold the current
>    state and the returned passwd structure.  (Placing these in a structure
>    which is passed to getpwent would complicate the calling program,
>    especially if the passwd file is examined in several places.)
>
>2)  malloc/realloc/free -- requires a global data structure to keep track
>    of which areas of memory are free.
>
>3)  stdio/exit -- needs a global variable so that exit can locate and close
>    all open files.
>					Kenneth Almquist

Kenneth, you should know better.  The answer is going to be separate the
function into two parts.  The first part we call "the hard part".  The
second part we call "the easy part."

The hard part deals with the issues that you raise concerning the persistent
state or other global static data.  The easy part is implemented using the
traditional techniques for pure-text programming, which is simply don't use
no global data, let the hard part provide you the address of the global
variables.

See my other recent posting describing how to construct the routines you've
listed above.  I'll admit that the statement "without global variables" was
very poorly worded.  In the context of the discussion, I intended to say
"without global variables in the shared library segment", since the topic
at hand is shared libraries.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."



More information about the Comp.unix.internals mailing list