Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!mordor!lll-lcc!ptsfa!amdahl!rtech!bobm
From: bobm@rtech.UUCP
Newsgroups: comp.unix.wizards
Subject: Of csh & filepointers & fopen calls ...
Message-ID: <638@rtech.UUCP>
Date: Tue, 3-Feb-87 20:57:09 EST
Article-I.D.: rtech.638
Posted: Tue Feb  3 20:57:09 1987
Date-Received: Thu, 5-Feb-87 04:49:56 EST
Organization: Relational Technology, Alameda CA
Lines: 46

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.

Take the following program which simply opens a file over and over again
until it fails and prints the number of the failed fopen(), and the last
error number (the obvious declarations omitted for brevity):

	++argv;
	for (count = 1; 1; ++count)
	{
		if (fopen(*argv,"r") == NULL)
		{
			printf("file %d, errno %d\n",count,errno);
			exit(1);
		}
	}

If you just run this thing, you get:

file 62, errno 0

This is on an ULTRIX system which allows 64 open files.  Fine.  Subtract
3 for stdin / stdout / stderr, realize that fopen() doesn't leave errno
set.  That's what you ought to get.  "exec" this thing under either ksh
or sh and you get the same result.  NOW, "exec" it under csh, and you get:

file 58, errno 24

24 is the error number for too many open files.  Two questions I'm curious
about:

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())?

You get this same result (4 fewer files / meaningful error number) on
a couple other systems (Pyramids and CCIs) except for the actual number
of files opened, which differs from system to system.  You also get this
result if you assure that you are opening different files, not that that
should make any difference.
-- 

Bob McQueer
{amdahl, sun, mtxinu, hoptoad, cpsc6a}!rtech!bobm