Date: Mon, 15 Jun 1998 09:30:40 +0300 (IDT) From: Eli Zaretskii To: George Foot cc: djgpp AT delorie DOT com Subject: Re: Signal handlers -- what can they do? In-Reply-To: <6m26d1$q5k$3@news.ox.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On 15 Jun 1998, George Foot wrote: > > Signals are numbered 0..255 for software interrupts and 256..287 for > > exceptions (exception number plus 256); other implementation-specific > > codes are specified in (see below). Every signal is given a > > mnemonic which you should use for portable programs. > > SIG* would seem to be "other implementation-specific codes", according > to this, and they seem to start from 288; so they're not software > interrupts and they're not exceptions. Oh, that one... You can just forget about the first 287 signals, as they were never implemented. (The idea was to have all the known interrupts and exceptions to generate distinct signals, but it was never done.) The truth is that some of the signals, such as SIGINT, are faked by the library when e.g. you press Ctrl-C, while others, like SIGSEGV, are generated in response to real CPU exceptions. The division is not well-defined (IMHO), which is why I asked what were you talking about. > I asked because in a number of places (within that documentation, and > in the library sources) it is said that the situation is different for > these types of signal. The main difference is that your handler cannot return from a real exception (if it does, the library will abort the program). It must either exit or longjmp. That's because if we let the handler return, the same reason for the exception (e.g., null pointer dereference) will happen again and again, ad nauseum.