Re: why do we put code onto the stack when doing a signal?

Mark Hemment (markhe@nextd.demon.co.uk)
Tue, 15 Apr 1997 11:40:42 +0100 (BST)


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
------------------------------------------------------------------