On Jun 9, 5:45 pm, thagor2...@googlemail.com wrote:
> On Jun 9, 4:26 pm, Pete Becker <p...@versatilecoding.com> wrote:

> > From the C99 standard: "If the signal occurs other than as
> > the result

> That C, not C++.

Included in the C++ standard by reference.

> > So, unless the signal came from a call to abort or raise,
> > the behavior is undefined.

> It may be undefined from the point of view of the C standard ,
> but not from the unix standard otherwise there'd be no point
> using signals - every time a handler was called you'd have to
> hold your breath and hope the program didn't crash!

Not if you only do things which are allowed in the signal
handler. Posix allows you to call a certain number of system or
library functions, in addition to what the C standard allows,
but it's still very limited. (Of course, if you're only under
Posix, you won't be using signal() anyway.)

> I'm only interested in the specific combination of C++
> exceptions and signal handlers since once stores the stack and
> one forces an unwind. Are compilers smart enough to know to
> pop the signal handler stack first and return to where the
> signal occured before unwinding the stack for the exception is
> the question.

The problem is that signals can arrive asynchronously. At a
moment, for example, when the stack frame isn't set up
correctly, and stack walkback isn't possible. In practice, it
is very, very difficult to implement it so that it can work
reliably, and I know of no system which does so.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34