levy@ttrdc.UUCP (Daniel R. Levy) (04/11/88)
In article <8042@elsie.UUCP>, ado@elsie.UUCP (Arthur David Olson) writes: # > If UNIX needed this facility, and if it used "b" to indicate binary mode, # > FILE *binin = fdopen(fileno(stdin), "rb"); # > FILE *binout= fdopen(fileno(stdout),"wb"); # > /* use bin_in, bin_out instead of stdin, stdout */ # > would do the job. Would this work in MSDOS? # # Whether or not it works in MSDOS, it wouldn't work in draft proposed ANSI C # (which lacks an "fdopen" function). Oh, GROAN. Why not? Sometims that's the most efficient way of getting a stdio stream open onto a file which needs options on open() or creat() other than the default, e.g. with permissions other than 0666&umask, or with a special open parameter like System V's O_SYNC. -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy | AT&T Data Systems Group | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/11/88)
In article <2567@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >Oh, GROAN. Why not? Sometims that's the most efficient way of getting a >stdio stream open onto a file which needs options on open() or creat() other >than the default, ... There is no fdopen() in ANSI C because there are no UNIX file descriptors in ANSI C. UNIX (POSIX) systems can provide fdopen() as an extension to an ANSI- conforming C implementation. Nobody is insisting that it go away, except it must not appear in <stdio.h> in a pure ANSI C environment (special implementation-dependent things may be done to enable its appearance; this issue is still being discussed by the standards committees).