[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Colascione
Subject: Re: Dynamic modules: emacs-module.c and signaling errors
Date: Wed, 25 Nov 2015 01:11:16 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 11/25/2015 12:50 AM, Daniel Colascione wrote:
> On 11/25/2015 12:24 AM, Paul Eggert wrote:
>> Daniel Colascione wrote:
>>> You could argue that file descriptors are basic. They're just handles to
>>> bits of kernel memory, right?
>> I'm not making that argument. I am arguing that memory allocation is
>> basic, though. It really is. It happens *all the time* in the C code
>> inside Emacs, and it's almost surely going to happen all the time in
>> module code as well. It should be easy, not a pain.
> Modules in C already have to handle checking for failures of their
> internal allocations. What makes checking for failures of Emacs-side
> allocations so much worse?
> There are ways of making working with Lisp easier while preserving
> robustness.

Another option for making the Emacs API more ergonomic might be to
define most functions to do nothing if we have non-local control flow
pending, even on otherwise-invalid inputs. (That's opposed to making
emacs_env calls with pending non-local control into a programming
error.) That way, you'd be able to write something like this...

int64_t vplus1 = env->extract_integer(env, env->eval_fmt(env, "(1+ blah
%v)", v));
if (env->error_p()) {
  return NULL;

... and preserve whatever went wrong inside eval_fmt, not abort or raise
some generic "invalid call to extract_integer" error.

I'm not sure that this scheme is a good idea, but it does make for
shorter code while still allowing us to propagate errors from any spot
inside Emacs.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]