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