From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: emacs-module.c and signaling errors Date: Wed, 25 Nov 2015 00:50:46 -0800 Message-ID: <56557666.9080408@dancol.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LEfmbR2H116LIjJ0RaJUFhsrGgqEPiLpk" X-Trace: ger.gmane.org 1448441479 13353 80.91.229.3 (25 Nov 2015 08:51:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2015 08:51:19 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Paul Eggert , Eli Zaretskii , Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 25 09:51:11 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 1a1VnC-0000Of-Aw for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 09:51:10 +0100 Original-Received: from localhost ([::1]:43941 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1VnD-0003Uf-Az for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 03:51:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1Vmy-0003UU-9B for emacs-devel@gnu.org; Wed, 25 Nov 2015 03:50:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1Vmx-0001PW-30 for emacs-devel@gnu.org; Wed, 25 Nov 2015 03:50:56 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:36919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1Vmw-0001PQ-Qe; Wed, 25 Nov 2015 03:50:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=hE6XI3SX3pvdNu9u2cCJ2MLWWMmNM3ofyHzKgSUJBaU=; b=DU1r3GAFs00kF25/AeUn7OgS8+HJTVG/6Yi0dNiSW3hua3Zcz2Czpftz9e1h9aqWRhPPWkqVa4voUEGZoHPSxBKAF7atMJrGsgtiV5wAWIC4Bbe3WcBZuRyR6czEbRR6y0q8/jtk+if99iOyc44LTPQOn1K8BgP/hPl4Ha0z3tB2Q6NyEmO3y0coq9FuFxUBw9LOg4Q+5qVZtyqq+Oid7oc4cB8BYKkavnl0XObgwEwaZnVj3ChetioemZHE5Ahpiv185v0dHVIZtbbkUVZbNuxPSId3DEdCi4js1dHFCvKxaxL+C75iP1QzwzCWyiwadJJeKHE4O7a2SyED+q7Ptg==; Original-Received: from [2620:10d:c090:180::4cf7] (helo=[IPv6:2620:10d:c081:1103:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1a1Vmu-000430-TA; Wed, 25 Nov 2015 00:50:52 -0800 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <5655702D.4040207@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:195218 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LEfmbR2H116LIjJ0RaJUFhsrGgqEPiLpk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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? >=20 > 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 =3D 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 =3D 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. --LEfmbR2H116LIjJ0RaJUFhsrGgqEPiLpk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWVXZmAAoJEN4WImmbpWBl/cQP/RmtY8d1tG+dOsDfXKBGPcMh MS/Ei5g3HAFzUHIeBj5VKHaG2WqzkxckKzw/UAgnf7tveBBj/uW/2Zh785mBQMO0 x7DfcvQPJvy+ZQRMJaAe7vEALMaZRIRf1EM1FGaNvLBnqfUA/oyxlRb0AeJciRcR 1Hbhy+ZA8Eo35FGqUqcs3kbZBPr6eA+UWH3ftZFoWFHe8REeCNN+dS7Sott1Geic jDsbjMEgBrrBDMxHdKSEzeXLE1kF3qQVOS13LiiXTaTcMPQxfBEF/lm76Y+I7UZW MHhYhl9LPZTZmnvZ0J5aN3Q3vt9pPjRrmfRhgDY9o3bc55J9cnXV6dODlbbSC2Wg 30ah15vi6NJcxgNi00AYxKDc9SOZpxbZtZsdjjn25MAKEvsgixNNd6VHxCtKCHRy byFLVAIp6avzCPhALCTiYOI2+5Ti2g1AuLj/+RakK3qb1EiM4IWo4uEiNPg84mIR lf/1uSQPtZ+edea0o2m4/HaCjGYBb8XnHm64BudqtL3clVvmdp87Rq3g6UdcVTPX eLAmIsnIgiPU/EIfVAS05ihKusJAVLNlXgdtJMqe7TYBhgkpHtJ9ECGKTMF42TlP 7ZdFA39Sd5LNqH5CRZDHeb/UFfFS8YUufWTA6y+dmIyqyFcPEfn7K5pd/YRmEPkd 6UObiGVDUudEoHvnTaSm =SyXb -----END PGP SIGNATURE----- --LEfmbR2H116LIjJ0RaJUFhsrGgqEPiLpk--