Xref: utzoo comp.lang.c:6846 comp.unix.questions:5291
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: Fate of fdopen(3S)??
Message-ID: <7166@brl-smoke.ARPA>
Date: 22 Jan 88 21:05:08 GMT
References: <2091@pdn.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20
Keywords: Draft ANSI C Std, POSIX

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.