TITLE: Using setjmp/longjmp with C++


PROBLEM: kanze@us-es.sel.de (James Kanze), 25 Jan 93

The C++ standards committee have said that they are adopting the C
library more or less integrally, so I would suppose that this means
setjmp/longjmp too.


RESPONSE: steve@taumet.com (Steve Clamage)

Yes, but with a caution.  If the longjmp bypasses destruction of 
automatic objects, the results are undefined.

In other words, if you have C code which uses setjmp/longjmp and is
otherwise legal C++ code, it will still be legal C++ code.  If you
add creation of auto objects which have destructors between the
setjmp and the longjmp, the code no longer has defined semantics.
(This could happen by calling a C++ routine from the original C code,
for example.)

The idea is to use exceptions rather than setjmp/longjmp in new code.


RESPONSE: jss@lucid.com (Jerry Schwarz)

The committee decided to include setjmp/longjmp, but with the
proviso 
 
    "If any automatic objects would have been destroyed as a 
    result of an exception passing control to the same function
    as the longjmp, the results of the longjmp are undefined."

In effect, this means that longjmp is present and will work the
way it does in C provided all your code stays in the C subset.
In code using constructors and destructors (what some people
might call "real C++") you shouldn't use it.  Note it isn't
just that the destructors may or may not be called, but the
exception handling mechanism itself might be corrupted by
use of longjmp.

I believe there were three points of view expressed during
the discussions leading up to this decision.

A) Not include them in the standard library. Vendors would be 
   free to continue to support them in any way they chose.

   The objection to this was that it might severely
   impact people trying to turn C code into C++. 

B) Include them and "fix them" to call the destructors (the
   way exceptions would). 

   The objection to this is that a lot of C++ code already 
   exists that uses longjmp/setjmp and doesn't expect the
   destructors to be called.  This alternative might 
   severely impact such code. And it would 
   make it  difficult to write code that works both
   with today's systems and future systems that implement
   this rule.

C) Include them and say they don't call destructors. 
   
   The objection to this is that the standard shouldn't contain
   a mechanism for subverting the usual guarantee that destructors
   are called when stack variables are deallocated.

I believe this will work out reasonably well.  People can continue
to use setjmp/longjmp.  As vendors phase in exception handling 
they ought to continue to support existing use of setjmp/longjmp
As systems without exceptions fade away programmers should discontinue
using setjmp/lonjmp.  (Although I personally think the transition
period will be measured in decades.)