Eli Zaretskii <eliz@gnu.org> schrieb am So., 22. Nov. 2015 um 17:23 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sun, 22 Nov 2015 09:03:39 +0000
> > Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com,
> emacs-devel@gnu.org
> >
> > We have already discussed longjmp at length in this thread, and Daniel,
> > Aurélien and I are all strongly against it. Using longjmp makes it
> effectively
> > impossible to write modules in any language but C, and even C code has
> to be
> > very careful (e.g. it can't use __attribute__((cleanup))). longjmp is
> only
> > possible within a monolithic system that is able to make closed-world
> > assumptions such as the Emacs binary itself, it is impossible in generic
> and
> > portable library code. We have worked hard to remove the possibility of
> longjmp
> > leaking into module code, and I won't put that possibility back in.
>
> I don't understand: we already have in emacs-module.c machinery that
> handles non-local exits.  Why cannot xmalloc do the same when it's
> called from emacs-module.c?
>

My impression was that Paul talked about code in modules, not code in
emacs-module.c. The latter can use xmalloc just fine, if appropriate
protection is installed first.