File descriptors and streams and copying thereof.

Geoff Clare gwc at root.co.uk
Fri Apr 28 19:15:30 AEST 1989


This is getting rather UNIX-specific, so readers of comp.lang.c who
aren't interested in what goes on "behind" fopen() etc. should hit 'n' now.


In article <731 at root44.co.uk> I wrote:
>It is, of course, safe to assume the stream returned by fopen() and
>friends has the lowest available file descriptor (i.e. fileno(stream)),
>...

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.  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).  Nowhere in the manuals that I have seen (v7,
>SYS V.2, BSD4.2, BSD4.3) does the open(2) system call or the fopen(3)
>library function guarantee that the file descriptor returned will
>be the lowest one available, only the dup(2) system call makes that
>guarantee.


I wasn't aware that there are still some backward systems around that
don't give this behaviour.  All of the many and various systems I have
worked on always give the lowest available file descriptor howsoever
it is obtained.  I still claim it is reasonable to assume this behaviour
because, in the future, all standards-conforming systems will guarantee it.

Open(), creat(), and dup() are all guaranteed to give the lowest available
file descriptor by the SVID, X/Open (XPG2 and XPG3) and POSIX.  POSIX also
guarantees this behaviour for pipe() (at least it says the two descriptors
will be the two lowest available - unfortunately it doesn't say the reading
side must be lower than the writing side, as one might assume).

As for fopen() etc.  POSIX says (8.2.3.1) "fopen() shall allocate a
file descriptor as open() does" and (8.2.3.3) "freopen() has the
properties of both fclose() and fopen()".

If anyone works on a system which doesn't behave like this, badger your
vendor to get it changed, because there are soon going to be a lot
of POSIX applications around which rely on it.

-- 

Geoff Clare    UniSoft Limited, Saunderson House, Hayne Street, London EC1A 9HH
gwc at root.co.uk   ...!mcvax!ukc!root44!gwc   +44-1-315-6600  FAX: +44-1-315-6622



More information about the Comp.lang.c mailing list