Not checking printf's result causes another news bug

[Guy Harris]

> 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