Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Pascal --> C question
Message-ID: <7550@brl-smoke.ARPA>
Date: 25 Mar 88 22:26:51 GMT
References: <302@goofy.megatest.UUCP> <225800017@uxe.cso.uiuc.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <225800017@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>Thus, as a corollary, if by some chance a C standard io stream gets 
>connected to a file that isn't stream, the results would be "system dependent",
>which implies that the implementer CAN'T BE WRONG! If VMS C connects to
>stream-LF files, then, and only then, would a flush be broken.

My understanding of the requirements in the draft proposed ANSI C
standard is that a conforming implementation is obliged to provide
(correctly!) at least one file format each for text streams and
for binary streams.  Although it may support more formats, it need
not do so.  However, vendors are well advised to attempt to do the
best job they can with each file format their system supports,
because it is not nice to tell the customer that C programs can
manipulate some kinds of files but not others.

Thus, technically, so long as VMS C had the right behavior on one
text stream format (stream-LF for example), the fact that it did
not handle other formats sanely would not make it nonconforming
in the strictest sense, merely broken.  I'm not sure if the fact
that it attempted to manipulate another format without reporting
an error couldn't be considered nonconforming, though -- I think
a case could be made that if a format is unsupported it shouldn't
pretend to work at all (i.e. fopen(), printf(), etc. should fail
on such a stream).