[comp.lang.c] Fate of fdopen

reggie@pdn.UUCP (George W. Leach) (01/22/88)

     Please excuse this question if this topic was covered.  The question
has only arisen due to a colleague wanting to use this library function.
The question concerns what is to happen to fdopen(2S)?

     Thomas Plum's "Notes on The Draft C Standard" indicate, as does the
Draft Standard(Oct,86 - I know it is an old copy), that only those functions 
dealing with a stream shall be treated in the ANSI C Standard.  Those dealing 
with file descriptors are left to POSIX due to the inherent dependence upon 
UNIX.

     Fine!  In fact, the simple fact that most of those functions dealing
with file descriptors are system calls and those dealing with streams are
library subroutines.  However, fdopen(2S) is an exception!  It is a library
subroutine that deals with file descriptors (but it returns a stream).

     The rational for leaving fdopen(2S) out of the Draft ANSI C Standard 
is quite reasonable.  However, how will POSIX handle this function?  Will
POSIX address those UNIX-specific library subroutines that fall out of
the Draft ANSI C Standard?  Or will they fall through the crack?

     I must admit that I am speaking out of total ignorance where POSIX is
concerned.  I have not been following that effort as I have been following
the ANSI effort with C.  How will the merged AT&T/Sun effort handle this?


Any Input Will Be Appreciated


-- 
George W. Leach					Paradyne Corporation
{gatech,rutgers,attmail}!codas!pdn!reggie	Mail stop LF-207
Phone: (813) 530-2376				P.O. Box 2826
						Largo, FL  34649-2826

gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/23/88)

In article <2091@pdn.UUCP> reggie@pdn.UUCP (George W. Leach) writes:
>     The rational for leaving fdopen(2S) out of the Draft ANSI C Standard 
>is quite reasonable.  However, how will POSIX handle this function?  Will
>POSIX address those UNIX-specific library subroutines that fall out of
>the Draft ANSI C Standard?  Or will they fall through the crack?

Draft 12 of the proposed IEEE Std 1003.1 (POSIX) includes a specification
for fdopen().  It is clear that this cannot be in ANSI C, since the whole
concept of a small-integer "file descriptor" is alien to the portable OS
environment and may not be the best way to handle open files in some
implementations.

By the way, POSIX had the declaration for fdopen() in <stdio.h>, with
no specific enabling method required.  This is in direct conflict with
the proposed ANSI C standard; this and other similar "turf conflicts"
in standard headers has to be resolved before some of the negative
ballots on 1003.1 will change to positive ballots.  It was intended all
along that a single C compiler/headers/library implementation be able
to simultaneously conform to both ANSI/X3.159-198x and IEEE Std 1003.1,
but this name space collision issue has yet to be worked out.

guy@gorodish.Sun.COM (Guy Harris) (01/23/88)

>      The rational for leaving fdopen(2S) out of the Draft ANSI C Standard 
> is quite reasonable.  However, how will POSIX handle this function?  Will
> POSIX address those UNIX-specific library subroutines that fall out of
> the Draft ANSI C Standard?

Yes.  See section 8 of Draft 12 of the POSIX standard, C Language Library,
which includes what you might consider routines that aren't in ANSI C and don't
belong there but are "related" to routines that are in ANSI C.  This section
includes "fileno" and "fdopen".

> How will the merged AT&T/Sun effort handle this?

The same way every other UNIX implementation handles it: provide "fdopen",
since the source is already there in SunOS and S5 (and S3 and V7 and 4BSD
and...).
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com