Xref: utzoo comp.lang.c:6570 comp.unix.questions:5151
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!whuts!mtune!codas!usfvax2!pdn!reggie
From: reggie@pdn.UUCP (George W. Leach)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Fate of fdopen(3S)??
Keywords: Draft ANSI C Std, POSIX
Message-ID: <2091@pdn.UUCP>
Date: 21 Jan 88 22:44:10 GMT
Organization: Paradyne Corporation,   Largo FL
Lines: 34


     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