Xref: news2.mv.net comp.os.msdos.djgpp:1194 From: Charles Sandmann 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: 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).