Hi Taahir, On Mon 23 Feb 2015 22:59, Taahir Ahmed <[email protected]> writes:
> 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 was thinking about this recently too, in the context of GDB's upcoming switch to C++, though I didn't get very far in the thinking. > 1) To check that I'm not duplicating any other ongoing work, Not that I know of. Doesn't matter anyway, a good solution is always acceptable :) > 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. Cool. > 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++. I am not C++-averse but a hypothetical move towards C++ in a Guile context doesn't necessarily mean moving towards use of exceptions. Scheme has fairly complicated control flow and embracing C++ exceptions doesn't necessarily solve things. For example an exception propagating over natively-compiled Scheme code would have to run dynwinds. Calling out to C++ would have to set up some sort of try/catch. Is that the right design? I don't know. (I do think that the C-stack-saving aspect of Guile's continuations is a silly thing, given that delimited continuations are more expressive, we can have escape-only continuations either way, and our VM and future native compilation pipeline means that we don't have so much rewinding of C stack frames, and in any case rewinding is unexpected and untested by most Guile core code, not to mention user code.) > 2) Replace all uses of set/longjmp with replacements (call them > eh_setjmp and eh_longjmp) that are based on libunwind [1]. No opinion other than a vague aversion to dependencies. > 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()). You are allowed to access variables that could never be assigned after the setjmp, AFAIK? Anyway how is mx accessed before being re-set after a prompt longjmp? Cheers, and thanks for looking at this, Andy -- http://wingolog.org/
