Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!mcnc!decvax!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: Testing I/O success (Was: Portable Self-Replicating C Contest)
Message-ID: <12744@haddock.ima.isc.com>
Date: 19 Apr 89 01:11:48 GMT
References: <12144@haddock.ima.isc.com> <12593@haddock.ima.isc.com> <8019@boring.cwi.nl> <25114@watmath.waterloo.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 20

In article <25114@watmath.waterloo.edu> rbutterworth (Ray Butterworth) writes:
|In article <8019@boring.cwi.nl>, siebren@cwi.nl (Siebren van der Zee) writes:
|>In article <12593@haddock.ima.isc.com> karl@haddock (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 ...
|>
|>[Can't be done, in general.]  As far as the contest (and _ANY_ serious
|>program) is concerned, you still have to check whatever you can, of course.
|
|... 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.

I ran into this issue as I was drawing up the rules, and I decided that, for
the purposes of this contest, the rule is satisfied if the program checks all
of its own I/O calls.  You needn't worry about the potential failure of the
implicit fflush()/fclose() in exit().

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
(If mail doesn't seem to be getting through, post a note to soc.net-people.)