Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Binary I/O on stdin/stdout?
Message-ID: <7747@brl-smoke.ARPA>
Date: 24 Apr 88 16:24:37 GMT
References: <7678@brl-smoke.ARPA> <281@quequeg.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <281@quequeg.UUCP> amen@quequeg.UUCP (Bob Amen) writes:
>	Perhaps I'm a bit confused here but it's always been my impression
>that UNIX was designed to make no distinction between binary and ASCII
> ...
>Why is this a problem now?  I've
>been following this discussion but have not yet heard a compelling reason
>to break one of the greatest advantages of UNIX.

You misunderstand.  UNIX need not (and undoubtedly will not) change in
this respect.  The discussion was about what should be specified in the
forthcoming ANSI C standard, which applies across ALL operating systems,
including some that would have great difficulty supporting a UNIX-like
notion of file.  Such systems often need to treat text files and binary
files in different ways.  The "b" specifier appended to an fopen() mode
requests that the stream be handled as binary; stdin/stdout/stderr are
required to be initially open as text streams.  On UNIX it makes no
difference, but on some systems this can pose a problem.

We were careful to permit text and binary streams to be indistinguishable
on systems where that was appropriate; the forthcoming IEEE Std 1003.1
(POSIX) requires this behavior, which is compatible with proposed ANSI C.