casts to void

[Peter da Silva]

> No, I want you to do something INTELLIGENT when a write operation fails.
> Properly-designed tools are NOT necessarily writing to a terminal
> with their printf()s; they may be writing into a disk file on a
> full filesystem or onto a communication link or a number of other
> possibilities.  By assuming that your program is always being run

OK. What should my whizzbang filter do when a write fails, other than
write an error message and quit? I really shouldn't test to find out
what stdout is, since I'm not supposed to behave any differently when
I'm writing to a file than when I'm writing to a terminal... I could
core dump, but what good will that do when it's out in the field? I
can look at errno & see if that helps... maybe if I get an EINTR I
should try to write again, but how do I know how much to write? Should
I delve into _IOB[1]? Hey, maybe there's something to the 4.2 signals
after all: they don't interrupt system calls! How about EIO? Since this
can occur on the call after the one on which it occurs I oughta do
a stack trace & see what I did last, so I can print a better error
message before quitting. EBADF. Now that could be useful. Most likely
it means SH didn't open stdout for me. Best not think about that.
ENOSPC. No space left on device. Better unlink my output file & temp
files before dying, if I have any, but I'm going to unlink my temp
files anyway and I can't do an funlink(), 'cos there ain't no such thing.
And besides the partial output may be of some use to someone.

Any other suggestions?
-- 
	Peter da Silva (the mad Australian)
		UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
		MCI: PDASILVA; CIS: 70216,1076