File descriptors and streams and copying thereof.

Doug Gwyn gwyn at smoke.BRL.MIL
Wed Apr 26 15:45:29 AEST 1989


In article <8624 at xanth.cs.odu.edu> kremer at cs.odu.edu (Lloyd Kremer) writes:
>In article <15039 at sequent.UUCP> bills at 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.



More information about the Comp.lang.c mailing list