Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pacbell!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.lang.c
Subject: Re: Binary I/O on stdin/stdout?
Message-ID: <4296@hoptoad.uucp>
Date: 1 Apr 88 14:15:29 GMT
References: <302@goofy.megatest.UUCP> <225800017@uxe.cso.uiuc.edu> <3221@haddock.ISC.COM>
Organization: Grasshopper Group in San Francisco
Lines: 42

karl@haddock.ISC.COM (Karl Heuer) wrote:
> In article <8036@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes:
> >> > There seems to be *no way* to "reopen" these streams as binary.
> >> There was a proposal for freopen((char*)0,mode,stream) to effect
> >> a change of mode on an open stream, but several implementors
> >> thought that switching modes in midstream could be difficult to
> >> support on some systems.
> Let's consider three classes of machines.  Those on which text and binary
> streams are identical (POSIX); those on which such a mode-change is impossible
> (probably because the mode is set in concrete when the file is first opened);
> and those on which it is neither trivial nor impossible.
> The proposed functionality is only useful on the third class.  Are there any
> such implementations?  (Where do MSDOS and VMS fall?)

Let me give you a specific example to chew on.  I have written a bunch
of programs for manipulation of image files in the Sun rasterfile format.
The particular format is not important to know except that it is binary.
Now, these programs are set up to accept a rasterfile on stdin, 
manipulate it, and produce a new one on stdout, so you can do things
like:

	<image scale .5 .5 | clip 0 40 300 300 | bwdither | lpr -v

This really works on Unix, and it would be pretty easy to make these
work on any system that could support binary files as stdin/stdout,
(and had a shell that would make pipes, like MSDOS or Unix), but not if
the standard doesn't tell me and those implementers a good way for me
to say "please sir, don't translate CR to LF on stdin for me, just let
me at the bytes"...

[As mentioned, MSDOS has this capability; as on Unix, "text" versus
"binary" is all in the application's head (the problems arise because
the default text format is not the one assumed by C programs from Unix).
Atari's TOS is the same way.  I'm not sure about AmigaDOS or the MacOS.
VMS has already been explained to be *unable* do handle this, but I
don't care if my stuff runs on VMS anyway.]

So I'm not asking for a *requirement* that all systems be able to handle
binary I/O on stdin/out/err, just a method for requesting it where possible,
to encourage portability to systems that are capable of it.
-- 
{pyramid,pacbell,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
"Don't fuck with the name space!" -- Hugh Daniel