PDA

View Full Version : Signals and library functions



Overworked_PhD
05-31-2008, 09:19 PM
This questions stems from a discussion on error handling in recursive functions on another forum. And I quote



>On May 30, 10:17=A0am, David Resnick <lndresn...@gmail.com> wrote:
>> Sure, and a fourth is to pass down a pointer to a variable to use for
>> error reporting.
>Yet another one is to use signal()/raise().

If the routine so invoked does not terminate with longjump
(and longjump was already proffered earlier in the list) then
when the routine returns, execution will resume with the return
of raise() (which will have a value of 0 if successful, non-zero
otherwise.)

signal()/raise() does have the advantage that the invoked routine
is able to access library functions, and is able to access static storage
that is not volatile sig_atomic_t (undefined behaviour if the
invocation of the signal'd routine does not come from raise()).
Effectively, signal()/raise() becomes a method for storing a hidden
global pointer to a subroutine that gets called when raise() is used...
nothing you couldn't easily duplicate. Hmmm, I bet there has already
been an IOCC entry (or five) that relied upon this...
--


How does signal/raise have the advantage that the invoked routine is able to access the library functions? Can someone give me an example?

Codeplug
06-05-2008, 11:11 AM
>> How does signal/raise have the advantage that the invoked routine is able to access the library functions?
I guess you could say it comes directly from the C standard...

If the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t, or the signal handler calls any function in the standard library other than the abort function, the _Exit function, or the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler. ...
The "real" reason is that the signal handler isn't called "asynchronously" when abort() or raise() is called - and so you can touch globals and library functions like normal.

Posix also adds kill() to the list of "ok to touch globals and lib functions from handler".

gg