checking close's return value

[Barry Shein]

For years I've suggested from time to time that there should be a
signal assigned for I/O errors which is by default OFF but can be
enabled calling signal(). It should call the signal handler with the
fd that caused the signal and the errcode it would have returned to
the call that generated it (possibly some indication of the system
call tho that might be hard.)

The advantage is that you don't have to wrap all your I/O's with
checks for errors (although I suppose there's still the grey area of
short read/writes, I think semantics can be worked out for that with a
little work.) Another advantage (similar) is that I can simply add a
few lines to an existing program (like cat) and now check errors
without hunting down every place it does I/O. More importantly, I
don't need the souces to a library to add error checking (assuming I
can return sanely.)

The disadvantages (and implementation difficulties) are several, the
worst being derived from the fact that the error will not be detected
until all I/O physically completes. This means that I could, if
nothing is done to prevent it, close a file and later receive a signal
on that fd that there was an I/O error even tho by now I have it
opened to a different file, very confusing. I suppose one semantic
requirement might be that if the signal is enabled then a close()
automaticallly implies an fsync() first, at any rate I don't think
it's too much of a rat's nest, I didn't say the change was trivial.

I dunno, if it's useful for SIGFPE it seems similarly useful for I/O.

P.S. Yes, I am fully aware of what a SYNAD is.

	-Barry Shein, ||Encore||