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.