guy@sun.uucp (Guy Harris) (08/20/85)
> You could set up a (in unix lingo) a signal handler and if any I/O error > occurred it would interrupt to that routine. Now this was on a per-write > (actually, per I/O) basis but what I have in mind here is to do something > like: > > #define printf eprintf > #define fprintf efprintf > > then add to main() something like > > signal(SIGIOT,myhandler) ; /* choose a signal, SIGIOT seems good*/ No, SIGIOT is what "abort()" causes (except on 4.xBSD - in System V it uses "kill" so that you can get SIGIOT even if you don't have an IOT instruction). In S3/S5/4.3BSD, you can use SIGUSR1; in older BSD releases, #define SIGUSR1 as 30, and in V7 #define it as 16. This signal (as the name suggests) is reserved for user program use. In System III and System V, though, there is a "software signal" mechanism - see SSIGNAL(3C). The claim is made there that "this facility is used by the Standard C Library to enable users to indicate the disposition of error signals", but this claims is false; nowhere in the C library is it used. I suspect it was intended for this purpose, but nobody bothered changing the library to use it. For those of you with non-S3 or S5 systems who have a source license, you can drop it in. > and something reasonable for myhandler() and finally: > > eprintf(fmt,a,b,c,d,e,f,g...) /* etc or maybe use varargs */ > { Or, preferably, use "vprintf" and its siblings if you have them. They come with S3, and with S5R2, but *not* with S5R1. They can be easily implemented in any system with "_doprnt" (S5R2 has it and that's how it implements them). Guy Harris
root@bu-cs.UUCP (Barry Shein) (08/24/85)
>Re: use SIGUSER, use SSIGNAL (actually don't), use vprintf (tho you >probably don't have it.) [followup by Guy Harris] Ok, maybe it's just late and I'm grumpy, but aren't we being a little distracting here? The point was a much broader one about introducing an interrupt mechanism for alerting a program to I/O errors, something distinctly not in UNIX, likely by choice as the designers were well aware of the IBM SYNAD handling. I wonder if FSIGEOF and FSIGERR should be added to fcntl.h alongside FASYNC to handle these situations, especially where a large piece of software (as noted in the article, most programs that use printf) is suddenly discovered to be deficient in write error handling. I dunno, so much of this stuff seems to reduce to 'you forgot a semi-colon' and the point gets lost, even though I am sure what you said was true. -Barry Shein, Boston University