From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani
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 j= ust handles to
>>> bits of kernel memory, right?
>>
>> I'm not making that argument. I am arguing that memory allocat= ion is
>> basic, though. It really is. It happens *all the time* in the C co= de
>> inside Emacs, and it's almost surely going to happen all the t= ime 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 =3D env->extract_integer(env, env->eval_fmt(env, "= ;(1+ blah
%v)", v));
if (env->error_p()) {
=C2=A0 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.