Xref: utzoo comp.lang.c:36004 comp.bugs.4bsd:1753
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!tuvie!vmars!hp
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Newsgroups: comp.lang.c,comp.bugs.4bsd
Subject: Re: Checking system call returns (Was Re: Complexity of reallocating storage (was users command crap))
Message-ID: <2308@tuvie.UUCP>
Date: 9 Feb 91 20:50:46 GMT
References: <14994:Feb207:10:4791@kramden.acf.nyu.edu> <15076@smoke.brl.mil> <91Feb4.235043edt.1032@smoke.cs.toronto.edu> <17398:Feb511:22:0891@kramden.acf.nyu.edu>
Sender: news@tuvie.UUCP
Followup-To: comp.lang.c
Lines: 24

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 |