Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!sdrc!thor!scjones
From: scjones@thor.UUCP (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: Question: signal and program termination
Keywords: signal, exit, termination
Message-ID: <147@thor.UUCP>
Date: 30 Jan 91 22:41:44 GMT
References: <87792@tut.cis.ohio-state.edu>
Organization: SDRC, Cincinnati
Lines: 46

In article <87792@tut.cis.ohio-state.edu>, meranda@iguana.cis.ohio-state.edu (deron meranda) writes:
> 1) Supposedly, any signal handler can be exited by returning from the
>    handler, or calling one of abort(), exit(), or longjmp().  However,
>    the use of longjmp() is discouraged because the signal could have
>    interrupted a non-atomic operation.  But couldn't the same scenario
>    occur by calling exit() within a handler?  Clearly, any cleanup
>    functions set up by atexit() would have to be called.  However, if
>    some data was left in an undefined state because of the signal,
>    then couldn't these exit functions completely fail?

The difference is that exit() exits from the program without the
interrupted operation ever being resumed.  Although it is possible
that the exit handlers could fail because an interrupted operation
left some global data in a fatally inconsistent state, careful
coding should be able to prevent fatally inconsistent states.  A
quality implementation should code all the library routines this
way.

> 2) I am not quite sure of the connection (or allowable connection)
>    between abort() and raise(SIGABRT).  What happens if the handler
>    for SIGABRT is set to SIG_IGN and later abort() is called?  Also,
>    what happens if a user supplied handler is installed for SIGABRT...
>    Since abort() is not permitted to return, what would happen if
>    the handler decided to call exit(), longjmp(), or even worse
>    abort() again, rather than strictly returning?  Would this defeat
>    the "no-return-permitted" characteristic of abort()?

abort() is required to raise(SIGABRT) and then, if that returns, exit().
That prevents problems with ignoring SIGABRT or catching it and then
returning.  If the handler calls exit(), that's fine too, since that
prevents abort from returning as well.

> 4) A simple one:  supposedly all signal handlers are permitted to
>    simply return, _except_ for those signals that indicate a
>    computational exception.  Among the ANSI defined signals, which
>    ones do indicate a computational exception?

You must be working from an old draft -- the final version explicitly
lists SIGFPE (which is the only computation exception signal defined)
and then mentions the possibility of other implementation defined
signals.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
Domain: scjones@thor.UUCP  Path: uunet!sdrc!thor!scjones
This sounds suspiciously like one of Dad's plots to build my character.
-- Calvin