Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!ima!ISM780B!jim
From: jim@ISM780B.UUCP
Newsgroups: net.lang.c
Subject: Re: Re: When does void make code less re
Message-ID: <149@ISM780B.UUCP>
Date: Wed, 27-Feb-85 01:21:14 EST
Article-I.D.: ISM780B.149
Posted: Wed Feb 27 01:21:14 1985
Date-Received: Fri, 1-Mar-85 06:47:22 EST
Lines: 31
Nf-ID: #R:utzoo:-508600:ISM780B:25500110:000:1803
Nf-From: ISM780B!jim    Feb 25 14:00:00 1985

>Actually, note that the asynchronous nature of Unix disk i/o can cause
>a real, live i/o error to be reported to a close() rather than to the
>write() that caused it.  Programs which really want to be paranoid *will*
>check the returned value from close() and fclose().

Not to challenge your point about checking for errors, but I
would like to clear a misconception.  The UNIX systems I am aware
of do no such thing.  They simply discard asynchronous write
errors (these *will* be recorded on the console and in the error
log, but will not be passed to user code).  The claim in write(2)
in some manuals that an error may be reported in a later write is
simply a lie.  iodone() for an ASYNC buffer calls brelse, which clears
B_ERROR.  Even if I/O errors were reported to later users of the buffer,
close would not get them because it doesn't use I/O buffers.
However, close on some devices may indeed encounter some sort of synchronous
non-transfer error.
And fclose definitely can produce an error (the error that *is* reported
and should be watched for is ENOSPC) since it generates a write() call.

>I am deeply suspicious of event-handling primitives; I don't think I
>have ever seen a good way of doing them.  Lots of bad ways, though.

There are very good systems that use a stack-discipline exception mechanism.
Upon an error, the most recently set error handler is given a chance to
interpret the error, and either provide a correction action at the point
of error, provide a failure alternative at a point of call (a la setjmp), or
pass the error (or a modified form of the error) to the next most recent
handler.  A system-established default handler at the bottom of the stack
will print a message and exit if no user-defined action is taken.

-- Jim Balter, INTERACTIVE Systems (ima!jim)