Checking system call returns (Was Re: Complexity of reallocating storage (was users command crap))

[Peter Holzer]

brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

>In article <91Feb4.235043edt.1032 at smoke.cs.toronto.edu> moraes at 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 at vmars.tuwien.ac.at                 |     Tony Rand |