chase@Think.COM (David Chase) write:

  } For longjmp thrown through C++, there are (basically) two opinions.
  }
  } Opinion #1 is: "longjmp called should act like a special exception
  }                 thrown, and it should have a defined behavior within
  }                 C++, probably running destructors, and perhaps able to
  }                 be caught".
  }
  } Opinion #2 is: "longjmp is called only under special circumstances,
  }                 and the stack may be in an unreliable state.  Therefore,
  }                 the C++ frames (and destructors) are discarded without
  }                 any code being run."

The committee decided (in London, I believe) that longjumping across
C++ code is an error that the compiler is not required to diagnose,
i.e., undefined behavior. Thus, there is no reliable, predictable
code behavior after such a jump, and there are no requirements on the
compiler.

daniel@lia.com

In article <1994Jan7.215107.1121@lia.com>, daniel@lia.com (Daniel Edelson) writes:
|> The committee decided (in London, I believe) that longjumping across
|> C++ code is an error that the compiler is not required to diagnose,
|> i.e., undefined behavior. Thus, there is no reliable, predictable
|> code behavior after such a jump, and there are no requirements on the
|> compiler.

I'm aware of that decision, but I regard it as the usual standards committee
"quality of implementation" wimp-out.  As a language implementor, I have to
decide what constitutes "quality", and (one hopes) provide it.  (For sake of
example) I've got to figure out what implementable "something" will please most
people, and be sure that I've got an explanation and a solution for those people
who are not pleased.  And no, it isn't the compiler writer's job to enforce
"good style" or "standards" with a big painful whack across the hands, though
a warning is often appreciated by the more discriminating programmers.

I believe that people will, in fact, longjmp across C++ activation records, and
they will want "something" to happen (this is partly a consequence of exception
handling being synchronous only -- people will still try to do asynchronous
things in the same ways that they did them in C).  It is very likely that
whatever is implemented, people will discover its behavior, and try to use it
(there exist people who use longjmp to leap from coroutine to coroutine).  I
wouldn't want to write programs like this, nor would I want to debug them, but
they will be written.

One could program longjmp so that it would detect C++ activation records and
crash the program with a diagnostic if such a jump were detected, but you'd
better hope that is actually what most people want to do all the time.  My guess
is that they will still want to be able to LJ over C++ records, but that they
will also want a tool that will tell them when they are in fact skipping
destructors when they do this (that is, as long as there are no destructors,
programmers will want the ability to longjmp over C++ frames).  (Compare this
with the C/C++ diagnostic tools like CodeCenter or Purify that let you detect
anomalies, but also let you selectively ignore them.  99.44% pure is still .56%
impure.)

David Chase, speaking for myself
Thinking Machines Corp.