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