Messages in this thread | | | Date | Tue, 15 Apr 1997 11:40:42 +0100 (BST) | From | Mark Hemment <> | Subject | Re: why do we put code onto the stack when doing a signal? |
| |
Hi,
On Tue, 15 Apr 1997, Mike Jagdis wrote: > On Mon, 14 Apr 1997, Mark Hemment wrote: > > When SA_SIGINFO is implemented, we can have a different number of > > arguments on the stack-frame for a signal handler. (SA_SIGINFO adds two > > extra arguments, a "siginfo_t *" and "ucontext_t *" - I must find time to > > do this...). > > If you do it please try and make it compatible with other Unix > flavours. SCO OS5 at least implements SA_SIGINFO on "standard" > signals (it doesn't have extended real time signals or queued > signals according to my tests). It would be a complete bugger > to have to try and reimplement signal handling in iBCS :-).
Er, hmmmm, (moment of embarrasment), I wrote the original SCO stuff. > The "standard" handler has (int, sigcontext) where sigcontext is > a Linux extension. The POSIX handler is (int, siginfo, sigcontext).
Last time I checked, POSIX said nothing about this (but that was some time ago). SA_SIGINFO (and hence siginfo_t and u_context_t) are SVID-III. > The better solution (IMHO) is to always deliver siginfo. It only > breaks a few non-portable applications anyway and the alternative > is increased complexity and bloat.
And it breaks iBCS2!
Regards,
markhe
------------------------------------------------------------------ Mark Hemment, Unix/C Software Engineer (Contractor) markhe@nextd.demon.co.uk http://www.nextd.demon.co.uk/ "Success has many fathers, failure is a B**TARD!" - anon ------------------------------------------------------------------
| |