NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/c/18962

Text File | 1992-12-29 | 2.7 KB | 55 lines

Newsgroups: comp.lang.c
Path: sparky!uunet!spillman!tye
From: [e-mail] (E. Tye McQueen)
Subject: Re: longjumping out of a signal handler
Message-ID: <[e-mail]>
Date: Tue, 29 Dec 1992 09:07:51 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Spillman Data Systems
Lines: 44

[e-mail] (David Adrien Tanguay) writes:
)ANSI 4.7.1.1
)   If the signal occurs other than as a result of calling the abort or
)   raise function, the behaviour is undefined if the signal handler calls
)   any function in the standard library other than the signal function
)   itself (with a first argument of the signal number corresponding to
)   the signal that caused the invocation of the handler) or refers to
)   any object with static storage duration other than by assigning a
)   value to a static storage durection variable of type volatile
)   sig_atomic_t.
)
)You cannot portably call longjmp from a signal handler (modulo abort/raise).

Thanks for all the good input on this.

I'd note that "portably" above refers to an ANSI C environment,
obviously.  Especially since most pre-ANSI C implementations don't
even have the raise() function nor sig_atomic_t type.  longjmp()ing
out of a signal handler can be ported across several flavors of
Unix, though such systems usually support more portable techniques.

My last (I hope) question is:  If you find yourself working on a system
where system calls or library functions, like read() or fread(), are
"restarted" for you after being interrupted by a caught signal, how do
you cause the system call or library function to fail (exit) so you
can go on to something else?  (I don't believe I have access to such
a system so I can't RTFM.)  I know I can use select() or similar
functions, if available, but in my porting environment that is much
less portable than longjmp()ing out.

Well, I do have one more thing I'm curious about.  I assume the
ANSI committee left the behavior of longjmp()ing out of a signal
handler undefined because it was felt that some systems would
find it very hard to support such actions.  Was this mostly for
non-Unix systems or is there some particularly hard task involved
in "fixing" some Unix system(s) to support it?  Or was it more that
the same purposes could be served via the sig_atomic_t stuff with
very little work for existing systems to support it?

Thanks again,
 [e-mail]                         Tye McQueen, E.
----------------------------------------------------------
 Nothing is obvious unless you are overlooking something.
----------------------------------------------------------