From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: emacs-module.c and signaling errors Date: Wed, 25 Nov 2015 18:26:31 +0000 Message-ID: References: <83k2p7xk13.fsf@gnu.org> <87wpt7p369.fsf@tromey.com> <83d1uzxgvw.fsf@gnu.org> <5654D7CF.90001@cs.ucla.edu> <5654DCDC.3090200@dancol.org> <56555A96.3040001@cs.ucla.edu> <56555D4F.10508@dancol.org> <56555FE6.4080702@cs.ucla.edu> <565560AD.1070700@dancol.org> <565561F9.6060405@cs.ucla.edu> <5655627D.3020200@dancol.org> <56556812.50105@cs.ucla.edu> <565568B5.4070802@dancol.org> <56556A26.8010207@cs.ucla.edu> <56556D69.3030104@dancol.org> <5655702D.4040207@cs.ucla.edu> <56557666.9080408@dancol.org> <56557B34.6090802@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bb04dc482e333052561996c X-Trace: ger.gmane.org 1448476010 16643 80.91.229.3 (25 Nov 2015 18:26:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2015 18:26:50 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Daniel Colascione , Paul Eggert , Eli Zaretskii , Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 25 19:26:47 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a1emF-0002dy-2A for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 19:26:47 +0100 Original-Received: from localhost ([::1]:47112 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1emG-0004us-OJ for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 13:26:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1emD-0004ue-2J for emacs-devel@gnu.org; Wed, 25 Nov 2015 13:26:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1emB-0001HC-Tj for emacs-devel@gnu.org; Wed, 25 Nov 2015 13:26:45 -0500 Original-Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:35519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1em9-0001GB-Nx; Wed, 25 Nov 2015 13:26:41 -0500 Original-Received: by wmuu63 with SMTP id u63so149214814wmu.0; Wed, 25 Nov 2015 10:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=PHCBhpSs7387XspEB6YdLoIbhPQKoWsBoAmIyu9Xfz8=; b=ae/VlPp/Yf/nsC/LM893U2IRMxsBYUaCrYHxSWvKInCeAeBDCFPQ60/vBN4ai99un2 wRQ2Ypq6yHH13M4xjbU0MWcFaD+exU+5ZCfsS8/uaIlJrp5bWDU/Kx+kyJuWc6mJy7Ku QI1IWASYOlKlf2wZE1utpE3q5rNdMROh0L5AH5ENnqp71tnHrjGMAMgAsCgNSOmifV5F U+0hmrsZYqKu0e77IVOAsq4zKCgRRgO+NzsErcZqkGjIw+OviacYcK9xDdK+ySRKOD9Q lS6wadJkKy3uQV1w4dPt9pOOu81R1/pee6n4iIeYNxtj0qJ/YPBtpMQLNd4slzgM1V0y QdRg== X-Received: by 10.195.13.135 with SMTP id ey7mr44004718wjd.25.1448476001097; Wed, 25 Nov 2015 10:26:41 -0800 (PST) In-Reply-To: <56557B34.6090802@dancol.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195239 Archived-At: --047d7bb04dc482e333052561996c Content-Type: text/plain; charset=UTF-8 Daniel Colascione schrieb am Mi., 25. Nov. 2015 um 10:11 Uhr: > 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. > > I'm not a fan of this idea. It is unlike all other C APIs I'm aware of and I think the behavior would be quite surprising to the module author. After all, it causes code to silently do nothing if doing something was requested. I see a couple of alternatives: - If an unhandled error is detected, crash unconditionally, even if checking is disabled. This would be consistent with the behavior of structured exceptions in popular programming languages, and would make bugs very obvious. - 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. --047d7bb04dc482e333052561996c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Daniel= Colascione <dancol@dancol.org&= gt; schrieb am Mi., 25. Nov. 2015 um 10:11=C2=A0Uhr:
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.


I'm not a fan of this idea. It is = unlike all other C APIs I'm aware of and I think the behavior would be = quite surprising to the module author. After all, it causes code to silentl= y do nothing if doing something was requested.

I s= ee a couple of alternatives:
- If an unhandled error is detected,= crash unconditionally, even if checking is disabled. This would be consist= ent with the behavior of structured exceptions in popular programming langu= ages, and would make bugs very obvious.
- 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 curren= t approach: crash if checking is enabled, ignore otherwise.
--047d7bb04dc482e333052561996c--