One of the nasty little surprises that ANSI C had was the fact that
local variables in functions that call setjmp aren't preserved on the
longjmp unless they are declared volatile.
This is obviously related to the exception mechanism in C++, which is
another non-local goto, and the same arguments for agressively optimising
compilers not to preserve the variables will apply.
My question therefore is - do C++ exceptions preserve non volatile
local varibles in the catching routine ?
The ARM seems to have nothing to say about this, which would imply that
they are preserved, but then we have a divergence from ANSI C.

---------------------------------------------------------------------
Tim Murnaghan                            "Just keep hitting the keys"
DESISCo
Harefield Place
The Drive
Uxbridge
Middlesex
UB10 8AQ

murnaghant@uproar.enet.dec.com (Tim Murnaghan) writes:
:
: My question therefore is - do C++ exceptions preserve non volatile
: local varibles in the catching routine ?

 Not that I am in a position to give a definite answer to this,
 but I can always offer my opinion:

 They must, or else lots and lots of programmers will experience
 extremely subtle and hard-to-find bugs when porting their code.

 I also think it is possible for optimizing compilers to deduce
 when a called function may throw an exception that is caught
 in the calling scope, by comparing the types of the possible
 exceptions for the called routine with the types of exceptions
 that will be caught in the calling scope.  (Or it could simply
 make all local variables used in catch blocks volatile).

 I think the compiler has all the information it needs to safely
 support both optimization and non-volatile variables in catch-blocks.

: The ARM seems to have nothing to say about this, which would imply that
: they are preserved, but then we have a divergence from ANSI C.

 I would not be the only divergence from ANSI C, and it is a nice
 one, adding important functionality (IMO).  And setjmp()/longjmp()
 will still be there for those who prefer them (perverse).

 BTW, "The C++ Progr. Lang., 2nd Ed." does say something about it
 (p322), it has an example where a non-volatile local variable
 is legally accessed in a catch block (although it is written,
 not read).

--
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------

murnaghant@uproar.enet.dec.com (Tim Murnaghan) writes:


>One of the nasty little surprises that ANSI C had was the fact that
>local variables in functions that call setjmp aren't preserved on the
>longjmp unless they are declared volatile.
>This is obviously related to the exception mechanism in C++, which is
>another non-local goto, and the same arguments for agressively optimising
>compilers not to preserve the variables will apply.
>My question therefore is - do C++ exceptions preserve non volatile
>local varibles in the catching routine ?
>The ARM seems to have nothing to say about this, which would imply that
>they are preserved, but then we have a divergence from ANSI C.

I don't think the situation with C++ exceptions is directly comparable
to setjmp/longjmp.  The latter are (almost) unconstrained.  The former
obey block structure.

In addition, catching an exception requires unwinding the stack to the
point of the handler declaration.  A longjmp does not unwind the stack,
but just partially restores the state of the computation as of the
point of the setjmp.  It's the "partial restoration" that causes the
confusion in C.

I think the discipline of exceptions means that the handler can expect
local variables (whose addresses are not taken) to have their old values,
whether or not they are declared volatile.  Note that in C, this is
not forbidden, but merely not guaranteed.  In any event, exceptions are
new in C++, not a modification of anything which exists in C.
--

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16