> From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

    > Tom> With non-local exits, you'll also need a mechanism for unwind
    > Tom> protection within C code.

    > Sure, but that's an implementation issue.

No, it's not.

The SRFI is slightly unclear but I understand the section "Signalling
errors from external code" to mean that a call to something like
SCHEME_ARGUMENT_TYPE_ERROR does not return to its caller, but rather
directly to Scheme.

I gather also that SCHEME_CALL may result in a non-local exit past the
caller.

Since the mechanism of these non-local exits is not specified and can
not be modified by C code, the FFI contains no provision for them to
perform unwind protection --- that's a serious omission.

Let's suppose that a single library, libA, using the FFI takes its own
steps -- it avoids SCHEME_CALL except where no unwind protection is
needed; it creates its own internal mechanism wrapping
SCHEME_ARGUMENT_TYPE_ERROR with an unwind protection mechanism.

And suppose that libB does the same, but differently.

Now I can not mix libA and libB in the same program.   That's why it's
an interface rather than an implementation issue.

(However, in my view, this issues is moot.  The best way to solve this
problem is to not create it in the first place.  Please see an
upcoming post about "flow of control".)

-t