Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!xanth!kremer
From: kremer@cs.odu.edu (Lloyd Kremer)
Newsgroups: comp.lang.c
Subject: Re: File descriptors and streams and copying thereof.
Summary: sounds like a strange system!
Message-ID: <8624@xanth.cs.odu.edu>
Date: 25 Apr 89 17:51:22 GMT
References: <15039@sequent.UUCP>
Organization: Old Dominion University, Norfolk, Va.
Lines: 35


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.

It would seem to imply that this system has two different "gimme a file
descriptor" kernel routines, one guaranteeing the lowest and one not.
Also, it is common practice for systems to create the first three descriptors
originally by the sequence open(), dup(), dup().  In this system, they would
have to use another (more complicated) method to guarantee that the three
open descriptors are 0, 1, and 2, rather than, say, 13, 0, and 1.  In other
words, it seems they would have to do more work *not* to guarantee that open()
returns the lowest.

I would say that the designers of that system have never ascended the Sacred
Mountain.  They have not fasted and meditated and finally attained the
Spirit of UNIX!  :-) :-)

(Flame resistant suit on!!)

-- 
					Lloyd Kremer
					Brooks Financial Systems
					...!uunet!xanth!brooks!lloyd
					Have terminal...will hack!