Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!tektronix!sequent!bills
From: bills@sequent.UUCP (Bill Sears)
Newsgroups: comp.lang.c
Subject: Re: File descriptors and streams and copying thereof.
Message-ID: <15177@sequent.UUCP>
Date: 26 Apr 89 23:28:17 GMT
References: <15039@sequent.UUCP> <8624@xanth.cs.odu.edu>
Reply-To: bills@crg2.UUCP (Bill Sears)
Organization: Sequent Computer Systems, Inc
Lines: 29

In article <8624@xanth.cs.odu.edu> kremer@cs.odu.edu (Lloyd Kremer) writes:
>
>In article <15039@sequent.UUCP> bills@sequent.UUCP (Bill Sears) writes:
>
>>It is NOT safe to assume that the file descriptor returned either
>>by open(2) or the fopen(3) family will be the lowest available file
>>descriptor.  Although this may be true on many machines, it is not
>>guaranteed to be the case (I have worked with a machine where this
>>did not always work).
>>only the dup(2) system call makes that guarantee.
>
>I do not dispute this observation in any way, although I find the
>existence of a system where open() does not return the lowest available
>descriptor quite curious.

I don't pretend to understand how the system was implemented, as I
didn't have source code for the OS.  I spoke about this at some length
with the owners of the system (a group of consultants who contracted
UNIX operating system and C language training) and neither they nor
I could fathom a decent reason for the above behavior.  The only idea
that even half made sense was that the OS kept a record of the next
available file descriptor.  This made a search of the file descriptor
table unnecessary when an open was called.  Of course this doesn't 
completely explain the problem, because some sort of search is still
necessary to find the next available file descriptor for the next call 
to open :-(Although the test programs did seem to reflect this behavior).
As I recall the system was a small 80?86 system running some variant
of UNIX, but I can't remember the specifics (I either never knew or 
have forgotten).