Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.UUCP
Newsgroups: comp.lang.c
Subject: Re: closing stdout
Message-ID: <1887@haddock.ISC.COM>
Date: Mon, 7-Dec-87 11:45:17 EST
Article-I.D.: haddock.1887
Posted: Mon Dec  7 11:45:17 1987
Date-Received: Sat, 12-Dec-87 10:08:57 EST
References: <442@cresswell.quintus.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 30

In article <442@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe)
writes:
>[I expected fclose(stdout) to work; Rich $alz agrees that it must.  However,
>the dpANS warns that] "A maximally portable program which relies on a file
>being created must write something to the associated stream before closing
>it."  (So yes, there could be a problem with fclose() when it DIDN'T write
>anything...)

The only "problem" with that situation is that you might get a nonexistent
file rather than an empty one.  It will still close the stream and return 0 on
success.

>I think the main point is that I can find nothing in the ANSI draft nor
>in any of the C manuals I have checked which explicitly says that you
>can close the standard streams.

Surely, in the absence of a statement to the contrary, the standard streams
must be assumed to have all the properties of explicitly opened streams.

>[Example showing how   putc(c, stdin)   does not always fail; the conclusion
>is that this is a bug in the UNIX stdio implementation.]

According to the Oct86 dpANS, "putc ... is equivalent to fputc", "fputc ...
writes ... to the output stream pointed to by STREAM".  Since stdin is not an
output stream, you have passed an inappropriate parameter (although the type
is correct).  Library functions are not required to domain-check their
arguments, therefore this is a user bug, not a library bug.  (Cf. passing a
NULL pointer to strcpy.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint