Date:	Mon, 15 Jun 1998 09:30:40 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	George Foot <mert0407 AT sable DOT ox DOT ac DOT uk>
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:	<Pine.SUN.3.91.980615092236.9030A-100000@is>
MIME-Version:	1.0

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 <signal.h> (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.

- Raw text -