siebren@cwi.nl (Siebren van der Zee) (04/10/89)
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. >Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint Siebren van der Zee, siebren@cwi.nl
rbutterworth@watmath.waterloo.edu (Ray Butterworth) (04/11/89)
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.
karl@haddock.ima.isc.com (Karl Heuer) (04/19/89)
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.)
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (04/21/89)
In article <8038@boring.cwi.nl> siebren@cwi.nl (Siebren van der Zee) writes: >In article <8019@boring.cwi.nl>, I, siebren@cwi.nl (Siebren van der Zee) wrote: >> You *CANNOT* detect disk-full always on unix, since I/O is lazy. > >As several people pointed out to me, I was wrong. Even though the actual >write may take place by the time that the program has exited, the disk- >blocks are allocated immediately. Only when the write fails, you won't >be notified, unless you call fsync(int fd). >This is true for 4.3 BSD, SunOS 3.5, Ultrix 2.2; every unix I could check. Part wrong still. The disk blocks aren't allocated until stdio has flushed it's buffers and called write(), etc. A common problem is programs which never fclose() their buffered files and rely on exit() to do so. ALWAYS flush after writes which must check for I/O success. -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 | "When everyone else complies InterNet: jfh@rpp386.Dallas.TX.US | I will too ..." UucpNet : <backbone>!killer!rpp386!jfh +------------------- -- Doug Davis --