On 09/13/2015 08:43 PM, Stephen J. Turnbull wrote:
> Daniel Colascione writes:
>  > On 09/13/2015 01:31 PM, Stefan Monnier wrote:
> 
>  > >> It's not possible to skip frames in module code using longjmp, so
>  > > 
>  > > Why not?
>  > 
>  > Because most C code isn't expecting to be unwound. Forcing non-local
>  > flow control on module code is completely unacceptable.
> 
> "Completely unacceptable" is nonsense.  Module code needs to be
> written the same way any other Emacs code is written, using various
> unwind-protect constructs.

Why? There is no positive reason to make Emacs module code resemble
Emacs core code. In fact, there's a strong reason to make Emacs module
code more conventional, because it'll improve the accessibility of the
API, which in turn will increase the quantity and quality of Emacs modules.

The Emacs core code has a lot of baggage. It's not practical to clean it
up today, but the module system is a greenfield project. There is no
reason to burden it the same way.

> If the module wraps external code that
> has state that persists past the unwinding, you also need to use the
> underlying code's own "unwind protection".

We shouldn't break this perfectly reasonable code:

void
foo()
{
  std::string x = something();
  emacs_bar(x.c_str());
}

longjmp()ing out of emacs_bar prevents any stack unwinding happening,
which means that any code that requires stack unwinding for correctness
needs to swap every Emacs API call in the equivalent of condition-case.
It's cumbersome, especially for any binding that isn't pure C.

Can you name an extension system for any other program that longjmps out
of its public API functions?