Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!pesnta!wjvax!brett
From: brett@wjvax.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Of csh & filepointers & fopen calls ...
Message-ID: <828@wjvax.wjvax.UUCP>
Date: Wed, 11-Feb-87 12:06:20 EST
Article-I.D.: wjvax.828
Posted: Wed Feb 11 12:06:20 1987
Date-Received: Fri, 13-Feb-87 20:45:07 EST
References: <638@rtech.UUCP>
Reply-To: brett@wjvax.UUCP (Brett Galloway)
Organization: Watkins-Johnson Co., San Jose, Calif.
Lines: 27

In article <638@rtech.UUCP> bobm@rtech.UUCP (Bob Mcqueer) writes:
>I ran across this while trying to figure out how to tell following an
>fopen() call that the reason it failed was due to too many open file
>pointers.
>WHAT is csh doing with those 4 extra file pointers it apparently has open?
>WHAT does csh set up differently which causes the errno 24 to be hanging
>around after the fopen call (I assume coming from the underlying open())?

I don't have source, but I will hazard a guess.  The stdio package allocates
a static list of NOFILE entries, where NOFILE is the number of file descriptors
which can be open; stdin, stdout, and stderr are set to be already open.
When you fopen(), the stdio package first must find an entry in this list; then
it must open() the underlying file.  Apparently, csh leaves some other
file descriptors open across the exec(), which the stdio package can't
know about.  Thus, the stdio package still has entries available when
it runs out of file descriptors.  However, if the shell only leaves
stdin, stdout, and stderr open, the stdio package runs out of FILE entries
and file descriptors at the same time.  However, it must check for a
FILE entry first; otherwise the open might fail and yet leave the underlying
file open. Thus, fopen() returns error because there are no FILE entries
left, and the stdio package is too stupid to simulate an EMFILE error in
that case.

-- 
-------------
Brett Galloway
{pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett