Stefan Monnier <
address@hidden> schrieb am Mo., 14. Sep. 2015 um 03:58 Uhr:
>>> 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. Emacs needs to return with an error indication set.
Hmm... I'm still not sure what's the issue.
AFAICT, the only odd case I can think of is the following:
1- Emacs calls some module code via the new API.
2- This code (which is Emacs-specific) will know about Fthrow.
Even if it knows about non-local jumps, in many cases it can't do anything about them except wrapping them. For example, longjmp is illegal in most C++ programs (and probably in most other languages as well).
3- It may call some non-Emacs-specific code from some other library.
4- This non-Emacs-specific code calls back to some Emacs-specific function.
Step 3 and 4 can be left out. The issue only requires that the plugin contains some code that is not suited for longjmp; e.g., all C++ code, no matter whether written specifically for Emacs or not.
5- This Emacs-specific function calls Fthrow/Fsignal.
Where the problem only shows if/when we reach point 5.
This problem can be handled between 4 and 5 by using an appropriate
internal_condition_case.
Partially yes. internal_condition_case with a Qt handler can indeed catch all signals, but this invocation is only possible from Emacs C code (using internal_condition_case), and the fact that signal and throw use longjmp is an implementation detail anyway, so the catch-all code needs to be inside the module code.