Path: utzoo!utgpu!watmath!rbutterworth
From: rbutterworth@watmath.waterloo.edu (Ray Butterworth)
Newsgroups: comp.std.c
Subject: Re: Testing I/O success (Was: Portable Self-Replicating C Contest)
Message-ID: <25114@watmath.waterloo.edu>
Date: 10 Apr 89 23:34:44 GMT
References: <12144@haddock.ima.isc.com> <12593@haddock.ima.isc.com> <8019@boring.cwi.nl>
Organization: U of Waterloo, Ontario
Lines: 23

In article <8019@boring.cwi.nl>, siebren@cwi.nl (Siebren van der Zee) writes:
> In article <12593@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
> >Note rule 3.  Output calls can fail (e.g. disk full); the program must detect
> >this condition and return the value EXIT_FAILURE to the execution environment.
> >This constant is defined in <stdlib.h>, which must therefore be included.
> 
> You *CANNOT* detect disk-full always on unix, since I/O is lazy.
> The last block of a file may be written to disk after the program
> has exited.  As far as the contest (and _ANY_ serious program) is
> concerned, you still have to check whatever you can, of course.

It isn't simply unix.
According to the pANS C, exit(EXIT_SUCCESS) "must do what it's told"
and return success status even if it can't successfully flush its
stdout buffer.
i.e. exit() is required to flush all its output buffers,
but programs that call exit() aren't supposed to rely on this.
Personally, I think that's a stupid concept, but that's what we got.  

Anyway, that means that in any program where you would like
to be as sure as you can that it really does exit correctly,
you must explicitly fclose all your stdio output streams,
being sure to check the fclose() return status.