Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!uakari.primate.wisc.edu!sdd.hp.com!apollo!goykhman_a
From: goykhman_a@apollo.HP.COM (Alex Goykhman)
Newsgroups: comp.unix.internals
Subject: Re: Shared Lib Question (ISC)
Message-ID: <519a6ad6.20b6d@apollo.HP.COM>
Date: 16 May 91 20:58:00 GMT
Sender: root@apollo.HP.COM
Reply-To: goykhman_a@apollo.HP.COM (Alex Goykhman)
Lines: 26

In article <7516@segue.segue.com> jim@segue.segue.com (Jim Balter) writes:
>In article <19256@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
>>There is a difference between `state' and `global variables'.  For example,
>>the stdio library you mention, could keep its state in the (FILE *) object
>>you pass as its argument in the `no global variables' version of our
>>stdio library.
>
>However, ANSI mandates that fclose(NULL) close all open FILEs, which requires
>a global pointing to the list of FILEs.  Of course, fopen could be a non-shared
>wrapper around a shared global routine; you would also need fopen and fdopen to
>be wrappers, since they need to hang new FILEs on the list.  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.

    Fclose(NULL) is only defined within the context of a single process, all it 
    needs to do is to go through the per-process fd table and and close every fd that
    remains open.  It should be easy to implement this call as a part of a shared
    library, and I am not sure what kind of overhead you are referring to.

[deleted]


Alex Goykhman                    speaking for myself  
Chelmsford System Software Lab   mit-eddie!apollo!goykhman_a
Hewlett-Packard, Company         goykhman_a@apollo.hp.com