emacs-devel
[Top][All Lists]
Advanced

[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 00:50:46 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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. I've previously proposed providing a utility function that
lets callers write expressions like this:

emacs_value v =
  env->eval_fmt(env, "`(foo (xyz . bar) ,%v ,%s ,(something %d))",
my_emacs_value, "blah", 42);
if(!v) { return NULL; } // Equivalently, if (env->error_p(env)) { return
NULL; }
do_something_with(v);

It's possible to implement eval_fmt mostly in Lisp, and it would let C
callers naturally construct arbitrarily complicated Lisp data structures
while only checking for errors in one place. Sure, it's not the fastest
thing the world, but in hot spots, modules can always drop down to the
very exact, but very verbose, API we've been complaining about here.

It should also be possible to write a function that pulls values out of
existing data structures just like destructuring-bind ---

char* key;
int value;
emacs_value some_plist = mumble;

while (env->is_not_nil(some_plist) && env->extract_fmt(env, some_plist,
"(%s %d . %v)", &key, &value, &some_plist)) {
  do_something(key, value);
  env->emacs_free(key); // extract_fmt allocated memory for the contents
of the string key using the internal emacs allocator
}
if (env->error_p(env)) {
  return NULL;
}

This way, it's possible to do fairly involved things while not checking
for errors at every single step.

It's also possible to implement eval_fmt and extract_fmt as library
functions written in terms of the current module API, but it wouldn't
hurt to provide them directly for the convenience of C callers.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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