I noticed some recent discussion of "longjmp" and C++.
There were some comments that exception handling makes
longjmp unnecessary.  Speaking as a heavy user of a language
with exceptions (Ada), let me warn you that normal exceptions do *not*
accomplish the same thing as setjmp/longjmp.

The problem is how to handle a Unix signal, hardware interrupt,
or equivalent, and change where the interrupted thread of
control is executing.  One option is to somehow raise
an exception in the signal handler, which is hopefully
propagated to the interrupted thread.  However, this
is a violation of the normal model of exceptions,
which are designed to be used as "synchronous" error indications.

It is probably possible to make "asynchronous" exceptions
work, but it is not trivial, and will need work on producing
the proper semantics for exceptions raised in signal handlers.
So, if setjmp/longjmp are not part of the C++ standard, then
kill (raise in ANSI C), signal, and asynchronous exceptions will have to be,
along with the various way to defer/ignore signals during critical
sections.

As a simple example where this capability is important, try
to construct a shell-like program which responds to a Control/C
by resetting its state and reprompting.  This example exposes most
of the issues associated with asynchronous transfer of control.

S. Tucker Taft       stt@inmet.inmet.com
Intermetrics, Inc.
Cambridge, MA  02138

In article <259400007@inmet> stt@inmet.camb.inmet.com writes:

> So, if setjmp/longjmp are not part of the C++ standard, then
> kill (raise in ANSI C), signal, and asynchronous exceptions will have to be,
> along with the various way to defer/ignore signals during critical
> sections.

But even in ANSI C, the effect of calling longjmp from within
a signal handler is undefined.
--
    --Andrew Koenig
      ark@europa.att.com