Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!caen!ox.com!emv
From: moraes@cs.toronto.edu (Mark Moraes)
Newsgroups: comp.archives
Subject: [comp.lang.c...] Checking system call returns (Was Re: Complexity of reallocating storage (was users command crap))
Message-ID: <1991Feb5.215034.14821@ox.com>
Date: 5 Feb 91 21:50:34 GMT
References: <21548@yunexus.YorkU.CA> <5883:Feb102:05:4991@kramden.acf.nyu.edu> <1991Feb2.045119.22199@zoo.toronto.edu> <14994:Feb207:10:4791@kramden.acf.nyu.edu> <15076@smoke.brl.mil> <91Feb4.235043edt.1032@smoke.cs.toronto.edu>
Sender: emv@ox.com (Edward Vielmetti)
Reply-To: moraes@cs.toronto.edu (Mark Moraes)
Followup-To: comp.lang.c,comp.bugs.4bsd
Organization: Department of Computer Science, University of Toronto
Lines: 47
Approved: emv@ox.com (Edward Vielmetti)
X-Original-Newsgroups: comp.lang.c,comp.bugs.4bsd

Archive-name: c/library/libc-c-news/1991-02-05
Archive: cs.toronto.edu:/pub/libc.c-news.shar.Z [128.100.1.65]
Original-posting-by: moraes@cs.toronto.edu (Mark Moraes)
Original-subject: Checking system call returns (Was Re: Complexity of reallocating storage (was users command crap))
Reposted-by: emv@ox.com (Edward Vielmetti)

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.