Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!dogie.macc.wisc.edu!uwvax!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: File descriptors and streams and copying thereof.
Message-ID: <10120@smoke.BRL.MIL>
Date: 26 Apr 89 05:45:29 GMT
References: <15039@sequent.UUCP> <8624@xanth.cs.odu.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

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.
>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!  :-) :-)

open(), dup(), etc. system calls are guaranteed to return the lowest
file descriptor not currently open for the process (when they succeed).
This has been codified in IEEE Std 1003.1, which also requires that
fopen() allocate a file descriptor as open() does.  There is no such
requirement on opendir(), which may or may not invoke open() depending
on implementation-specific circumstances.

Of course, systems that do not attempt POSIX conformance may do as
they please.  Non-UNIX systems may not even have an inherent notion
of file descriptor as a small integer index involved in their fopen()
implementations.