Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: ANSI C Standard, Query
Message-ID: <8738@smoke.BRL.MIL>
Date: 23 Oct 88 00:45:09 GMT
References: <881014204352.505039@PCO-MULTICS.HBI.HONEYWELL.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

In article <881014204352.505039@PCO-MULTICS.HBI.HONEYWELL.COM> RStallworthy%PCO@BCO-MULTICS.HBI.HONEYWELL.COM writes:
>In looking at the section (4.9.2) on "streams", it refers to streams of
>two types, "binary"  and "text".  Elsewhere it refers to binary files
>and text files, as if there were two distinct file types, such that a
>binary file could only be read / written as a binary stream and a text
>file could only be read / written as a text file.  Now I am aware that
>the standard does not require this to be the case, but is there anything
>in the standard that would prevent it from being implemented in this
>way.

Nope.  An attempt to open a file may fail for any reason the implementation
chooses, including fopen() mode not matching the inherent file type.

Naturally, an implementation that can do a better job should be encouraged
to do so, but that is what X3J11 terms a matter of "quality of
implementation".