Xref:	news2.mv.net comp.os.msdos.djgpp:1194
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: signals
Date:	Tue, 13 Feb 1996 20:31:21 CST
Organization:	Rice University, Houston, Texas
Lines:	20
Message-ID:	<31214979.sandmann@clio.rice.edu>
References:	<DMp63t DOT 2vv AT granite DOT mv DOT net>
Reply-To:	sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host:	clio.rice.edu
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> All POSIX signals are "handled" - you can pass any of them to raise() and your
> signal handler will get called.  The question is, how many of them are
> *called* when POSIX says they should be?  I think the register dump is part of
> the default signal handler, so whenever you see it dump and say "due to signal
> SIGXXX", you could have added a signal handler for that.

I would classify signals as functionally in place, but not reviewed per POSIX
to see if all of the details are correct (partly because I was too busy and 
too cheap to get a copy of the standard).  I know, for example, that signal
masks are not implemented at all, that termination signals don't get sent,
and that signals across processes aren't properly handled in some cases.

But things like SIGFPE and SIGINT should work.  There is always room for
improvement, especially in this code, since it hasn't been substantially
modified since the prototype around 2 years ago.  And yes, the register
display and traceback are part of the default handler - so if you establish
your own signal handlers you can do whatever you want with the information,
like supress it, write it to a file, longjmp to a controlled fixup routine,
whatever.  Programs like GCC now print the nice "compiler error, submit
bug" instead of the register dump they did in V1.x (since they catch signals).

- Raw text -