Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!ukc!axion!stc!root44!gwc
From: gwc@root.co.uk (Geoff Clare)
Newsgroups: comp.lang.c
Subject: Re: File descriptors and streams and copying thereof.
Message-ID: <742@root44.co.uk>
Date: 28 Apr 89 09:15:30 GMT
References: <15039@sequent.UUCP>
Reply-To: gwc@root44.UUCP (Geoff Clare)
Organization: UniSoft Ltd, London, England
Lines: 46


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@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@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).  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@root.co.uk   ...!mcvax!ukc!root44!gwc   +44-1-315-6600  FAX: +44-1-315-6622