Re: Dynamic modules: emacs-module.c and signaling errors

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Mi., 25. Nov. 2015 um 20:19 Uhr:

> > - Ignore unhandled errors, proceed as if no error happened. This would be
> > consistent with popular C APIs such a the C standard library itself and
> POSIX.
> > - The current approach: crash if checking is enabled, ignore otherwise.
>
> The simple patch I sent a few minutes ago, according to Tom's
> suggestion, should cause such errors to signal a Lisp error from
> module-call.  I think this is what we should do.
>

Yes, I think that's better than crashing, longjmping, and also the current
approach. Ignoring unhandled errors would indeed have the potential to
swallow errors, unless we saturate the error state (i.e. never set it to
successful except in clear_error). So now I think that your patch indeed is
the best solution.

Maybe we should further reduce the amount of undefined behavior. Currently
e.g. passing null pointers is undefined behavior that will typically crash
Emacs. We could make this more robust by signaling an error instead; the
overhead should be minimal.

[-- Attachment #2: Type: text/html, Size: 1391 bytes --]