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: Tue, 24 Nov 2015 23:52:21 -0800 Message-ID: <565568B5.4070802@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MUOeeqSSA7n4FgJkwWXI4OnS9HdFrvhAT" X-Trace: ger.gmane.org 1448437962 24019 80.91.229.3 (25 Nov 2015 07:52:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2015 07:52:42 +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 08:52:39 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 1a1UsS-0000Qs-QR for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 08:52:32 +0100 Original-Received: from localhost ([::1]:43711 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1UsU-0006Er-2v for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 02:52:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1UsQ-0006EP-Ko for emacs-devel@gnu.org; Wed, 25 Nov 2015 02:52:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1UsP-00028b-Pd for emacs-devel@gnu.org; Wed, 25 Nov 2015 02:52:30 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:36581) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1UsP-00028B-Ga; Wed, 25 Nov 2015 02:52:29 -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=BYLcqPrK6mI9Ao6LCxIcKzDLSOWl9n4qUOm/nmwlbl8=; b=aoEEecnaMwW+M9FLXnwcwHI/rleBbrJICcxgHNKPhY6s+bJ6KvzFOyTfEC4ApH9jAmN/TDYG0I5XITWnhCjwCvdOGAms3SGP5KfYp/FYKJ2h5iNoMWA1IZvAXmIpPWKDjGizLq1931H+Y2MEKoNNOV+SosdSo4ywTFNncaaY+Vqb1YI/T5W2a487+WKpAmX40JoyGh9k9YszCmX6pEEMy84jtZL72v4IFSYxY2cap9KHoJn0DKbE+5NSdncpK/0hou+MWqxeYxQ81bvtYw4Kbj6FbgIH66+tOfkKOIu6UUqaa75U5vOW8VnZ1Ieuxzm2ydZE/e3wyjXCmMuv/JN46w==; 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 1a1UsN-0003gg-Qu; Tue, 24 Nov 2015 23:52:27 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <56556812.50105@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:195214 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MUOeeqSSA7n4FgJkwWXI4OnS9HdFrvhAT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/24/2015 11:49 PM, Paul Eggert wrote: > Daniel Colascione wrote: >> In a module API, we have to rely on traditional error checking. >=20 > No we don't. We certainly do not rely on it for checking stack space > exhaustion. And we don't have to rely on it for heap space exhaustion > either. What's your alternative? Assuming memory allocation never fails? That's unacceptable in robust programming. I disagree that it's tedious to check for allocation failure. We can QUIT almost anywhere too: do you think we should use some kind of special reporting mechanism for that too= ? I don't think having to check for errors is a particularly onerous requirement when writing C code. --MUOeeqSSA7n4FgJkwWXI4OnS9HdFrvhAT 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 iQIcBAEBCAAGBQJWVWi1AAoJEN4WImmbpWBlWWUP+wZTCn2U837lXB5bdj+2IvwW M0dORQ4DI+1ge3KNm/g6XmyLqdTML0VU3ivI5zr+OsO3lUU4la3LXS7wgZ1I/O/z FQt6AUFLehQYAmK+oAPuz9UKM9Fj0ZWrslw5D/cAqOYI792gSVwYqe5HgdxNco02 +HMJm5lxRq9kP94pOzsadiFlAD4YPqn5/9uZ4UYlHCxD0Fg7LJf5PeKLeH2m7q5Y Ql7D52BySJ1vb1PMuBCKV4YI3A9eeRoFj9VNlHEGWPjPgKI+IB/ro6REOG3IkpyE u1Znk4fgJg71RMRUBQdD39AEx5BCCFtabWF5QSJU0Jx7ldzlEnYG/TccKiKlfnsb WN0SeK++lFMar+sMkngaJNTez+pEcwLfwCWq4cq1Bv/dDsr6YI2fELGkHZUSxAZy co+bx/jSyHcxeA5AdiKuahtItfRwc54HisurENumkOtdU6chmuqR6fM1rj885JoY qPwGEhbioZiG8qaPwWn1RWfJVHsqeX+yM19rSCPtMNPMXI0ut/hziUpGcp4PkNw7 +F4LfUC7+MBlryfU0lHB03is0bcpUCA73rKlMPKUkBXXmQi8Dm3X9+/yHvMWWJuy IUZAWScVuOxNTKlxfxJhPqE5VppUCxKadxUHOociqKIxdovrcIBKa0MBTFfPfj1r 7feRCpVXJDNv65e5/erj =/F/F -----END PGP SIGNATURE----- --MUOeeqSSA7n4FgJkwWXI4OnS9HdFrvhAT--