Exception-safety for C++ code integrated with Guile.

[Taahir Ahmed <ahmed.taahir@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

Over the past few days, I've been working on reducing the amount of
defensive coding that is required when writing Guile extensions using
C++.

My primary goal is to ensure that destructors of automatic variables
are called if any Guile non-local control flow passes through a C++
stack frame.

I'm writing to the list for three purposes:

  1) To check that I'm not duplicating any other ongoing work,

  2) To float two different implementation strategies and see which
     one is the best choice going forward, and

  3) To get clarification on some issues that I've encountered with a
     prototype implementation.

The two major strategies I considered are:

  1) Replace all uses of set/longjmp in the Guile source with C++
     exceptions.  This approach is simple in some ways, and
     complicated in others.  I would hesitate to pursue this unless
     Guile has some sort of longer-term plan to move towards C++.

  2) Replace all uses of set/longjmp with replacements (call them
     eh_setjmp and eh_longjmp) that are based on libunwind [1].
     eh_longjmp uses libunwind to walk up the stack, calling each
     frame's personality routine [2].  This approach will requires a
     platform that uses DWARF exception handling (i.e., everybody
     except non-Cygwin Windows).  It has the potential to make calls
     to setjmp much faster, but calls to longjmp would take linear (as
     opposed to constant) time in the number of stack frames crossed.

I've started working on a proof-of-concept for option 2 (heavily
cribbed from libunwind's own set/longjmp replacement).

However, I've run into an issue --- many of Guile's uses of setjmp
don't conform to the C standard.  In particular, after experiencing a
non-local return from setjmp, you're not allowed to access any
non-volatile local variables, but Guile does (see the local variable
mx in eval()).

In effect, Guile is assuming that setjmp saves and restores registers,
but the standard doesn't require that behavior from setjmp.  I can
make my setjmp implementation save all registers, but I decided to
first check and see if this was a conscious decision to embrace
nonportability, or an accidental one.

Thanks,

Taahir Ahmed

----------------------------------------------------------------------

[1] http://www.nongnu.org/libunwind/index.html
[2] http://mentorembedded.github.io/cxx-abi/abi-eh.html#base-personality

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]