Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dgcad!dg-rtp!hunt
From: hunt@dg-rtp.rtp.dg.com (Greg Hunt)
Newsgroups: comp.unix.programmer
Subject: Re: more on error checking (was: Complexity of reallocating storage)
Message-ID: <1991Feb12.143940.29828@dg-rtp.dg.com>
Date: 12 Feb 91 14:39:40 GMT
References: <1991Feb07.013637.6542@convex.com> <1991Feb12.011911.7677@comp.vuw.ac.nz>
Sender: usenet@dg-rtp.dg.com (Usenet Administration)
Reply-To: hunt@dg-rtp.rtp.dg.com
Organization: Data General Corp., Research Triangle Park, NC
Lines: 51

In article <1991Feb12.011911.7677@comp.vuw.ac.nz>, duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
> 
> 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?

I'd rather not see it myself.  I already have code in which I print out
a message when I get SIGSYS (bad argument to system call), and then
ignore the signal, thus returning control to the code that made the
bad call.  It then (supposedly) gets error EINVAL, and since I'm
checking the error returns from my system calls, I then print out
what system call I was trying to do, what error I got, and any other
information I can provide, such as the name of the file I was reading
or writing if it was a file system related call.  I do similar error
reporting for any error from any system call that my code is not
prepared to deal with (you can correctly surmise from this which side
of the "should I check error returns from system calls" debate I'm on).

You mentioned in your second paragraph that you'd want to pass such
information somehow so that the signal handler can print it out for
you.  I think it is easier to handle such errors by checking the
return from the system call.  It would also allow you to print out
a large amount of information that it might be difficult to do with
a single parameter to a signal handler.  For me, coding error handling
where the error occurs certainly makes the code easier to understand.

I agree with your last statement.  It's a non-starter.  That's my
opinion, too.

-- 
Greg Hunt                        Internet: hunt@dg-rtp.rtp.dg.com
DG/UX Kernel Development         UUCP:     {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC, USA  These opinions are mine, not DG's.