moraes@cs.toronto.edu (Mark Moraes) (02/05/91)
In <14994:Feb207:10:4791@kramden.acf.nyu.edu>, Dan Bernstein observes
that certain system calls in a fragment of pty code are either
"guaranteed to work" or "cannot fail", that the "only possible
response to a fatal error would be cutting off the user program from
its input and output". I find it hard to believe that anyone in the
programming profession can make such statements so emphatically.
Responding to a system call failure by at least printing a warning
message would be better than blithely carrying on, especially in a
program that has to be installed with root privileges to work most
effectively. In a system call that's unlikely to fail, it's even more
important to know of failure. To quote Brian W. Kernighan and Rob
Pike, "The UNIX Programming Environment" (Prentice Hall. ISBN
0-13-937699-2)
It is worth noting that at least two thirds of the code in sv is
error checking. In the early stages of writing a program, it's
tempting to skimp on error handling, since it is a diversion from the
main task. And once the program "works," it's hard to be
enthusiastic about going back to put in the checks that convert a
private program into one that works, regardless of what happens.
...
But discs run out of space, users exceed quotas; communication lines
break. All of these can cause write errors, and you are a lot better
off if you hear about them than if the program silently pretends that
all is well.
The moral is that error checking is tedious but important.
The error() function in K&P helps make checking system call returns
and the printing of sensible error messages much simpler -- only one
extra line per system call. Save yourself some typing by snarfing the
one in C News, libc/warning.c and get a useful warning() routine
thrown in for no extra charge. :-) (The C News libc utility routines
can also be ftp'ed as an independent package from cs.toronto.edu as
libc.c-news.shar.Z.)
Mark.
---
"Don't assume God likes you: open and fopen will fail." -- Ian Darwin
and Geoff Collyer.brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/05/91)
In article <91Feb4.235043edt.1032@smoke.cs.toronto.edu> moraes@cs.toronto.edu (Mark Moraes) writes: > Responding to a system call failure by at least printing a warning > message would be better than blithely carrying on, How do you propose to do this, given that the program in question generally doesn't have a stderr to send messages to? If your answer is ``syslog,'' has it occurred to you that any syslog implementation must either lose messages in some cases or must allow a denial-of-service attack by one program upon all others that use the service? (UDP-based syslogs have the first problem. Named pipe/UNIX-domain socket-based syslogs have the second problem.) ---Dan
hp@vmars.tuwien.ac.at (Peter Holzer) (02/10/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <91Feb4.235043edt.1032@smoke.cs.toronto.edu> moraes@cs.toronto.edu (Mark Moraes) writes: >> Responding to a system call failure by at least printing a warning >> message would be better than blithely carrying on, >How do you propose to do this, given that the program in question >generally doesn't have a stderr to send messages to? If your answer is >``syslog,'' has it occurred to you that any syslog implementation must >either lose messages in some cases or must allow a denial-of-service >attack by one program upon all others that use the service? (UDP-based >syslogs have the first problem. Named pipe/UNIX-domain socket-based >syslogs have the second problem.) Even if syslog can fail (every program can fail), it won't do so in most cases. So at least trying to send an error message to syslog is much better than doing nothing. If you do nothing that might fail you won't get much done. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |