🚀 go-pugleaf

I have some questions about the ANSI defined behavior of signals
and program termination.

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?

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()?

3) I would assume that signal handlers are permitted to raise other
   signals.  Say, if the default action for SIGINT's handler was to
   terminate the program, would it be more appropriate to raise
   SIGABRT or SIGTERM -- or should it just call exit() and suffer the
   same problems mentioned in question 1?

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?

Thanks!

Deron E. Meranda  ( meranda@cis.ohio-state.edu )