Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!bbn.com!rsalz
From: rsalz@bbn.com (Rich Salz)
Newsgroups: comp.lang.c
Subject: Re: closing stdout
Message-ID: <253@papaya.bbn.com>
Date: Sun, 6-Dec-87 15:36:56 EST
Article-I.D.: papaya.253
Posted: Sun Dec  6 15:36:56 1987
Date-Received: Fri, 11-Dec-87 06:44:31 EST
References: <437@cresswell.quintus.UUCP>
Reply-To: rsalz@bbn.com (Rich Salz)
Followup-To: poster
Organization: BBN Laboratories, Cambridge MA
Lines: 25
Summary: If it's not safe, it's a buggy library

Richard A. O'Keefe is concerned about being able to fclose(stdout)
and friends, apparently based on mail from Roberto Shironoshita at the
University of Pennsylvania who warns that "fclose() generally tries to free()
things, and this might cause trouble for stdout. ..."

NONSENSE!

If there are no bugs in your program (e.g., corrupted malloc arena, so
that a free would fail), then it is *ALWAYS* safe to fclose() anything
that has been fopen'd for you implicitly, or by you explicitly.  This
include stdin, stdout, and stderr.  If this is not the case, then you
have a severely broken C library, and should be on the phone with your
vendor right away.

First make sure it's not your bug.

If you want to ensure that the data you have fprintf'd or such has been
forced out of any STDIO buffers (and is put out into the appropriate
Unix kernel buffers), then fflush() is all you need.  Doing fclose is
wrong if you have additional output, because:
	fclose(stdout);
	printf("I wonder what will happen?\n");
is guaranteed to be an error, and may in fact cause your program to crash.
-- 
For comp.sources.unix stuff, mail to sources@uunet.uu.net.