Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!comp.vuw.ac.nz!duncan
From: duncan@comp.vuw.ac.nz (Duncan McEwan)
Newsgroups: comp.unix.programmer
Subject: Re: more on error checking (was: Complexity of reallocating storage)
Summary: Anyone for a failed system call signal?
Message-ID: <1991Feb12.011911.7677@comp.vuw.ac.nz>
Date: 12 Feb 91 01:19:11 GMT
References: <1991Feb07.013637.6542@convex.com>
Sender: news@comp.vuw.ac.nz (News Admin)
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
Lines: 27
Nntp-Posting-Host: bats.comp.vuw.ac.nz

In article <1991Feb07.013637.6542@convex.com>, Tom Christiansen writes:
>As was mentioned earlier, *every* system call should *always*
>be checked, even if you "know" it can't fail.

I'm not sure if this has been discussed in this thread yet, but
one possibility that I've seen suggested elsewhere is to have
failing system calls generate a signal to the calling process
(SIGSYS2 anyone?).  The default action might be to terminate the
process, though perhaps printing a diagnostic and resuming would
be more compatible with current behaviour.  I can't offhand think
of any particularly nice way of implementing a libc provided default
handler that could do the latter without messing with the compilers
or crt0.o, etc, though.

It would be nice if such a scheme could be implemented entirely
without kernel support (perhaps by putting the signal generating
stuff in the libc wrappers for each system call), but I don't think
that would allow passing a parameter to the handler (which you would
want, to give information about what system call failed).

Hm, thinking about it, this all sounds a bit VMSish, and if its
only aim is to provide protection from programmers who don't check
every syscall, then its probably a non-starter :-)

Comments, suggestions, flames, anyone?

Duncan