Xref: utzoo comp.lang.c:35802 comp.bugs.4bsd:1731
Path: utzoo!utgpu!watserv1!watmath!att!linac!uwm.edu!spool.mu.edu!uunet!snorkelwacker.mit.edu!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
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: <17398:Feb511:22:0891@kramden.acf.nyu.edu>
Date: 5 Feb 91 11:22:08 GMT
References: <14994:Feb207:10:4791@kramden.acf.nyu.edu> <15076@smoke.brl.mil> <91Feb4.235043edt.1032@smoke.cs.toronto.edu>
Organization: IR
Lines: 13

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