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: MODULE_HANDLE_SIGNALS etc. Date: Sun, 3 Jan 2016 11:04:08 -0800 Message-ID: <568970A8.8000305@dancol.org> References: <83mvu1x6t3.fsf@gnu.org> <56772054.8010401@cs.ucla.edu> <83zix4scgf.fsf@gnu.org> <5677DBC9.6030307@cs.ucla.edu> <83io3rst2r.fsf@gnu.org> <567841A6.4090408@cs.ucla.edu> <567844B9.2050308@dancol.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.org> <5678D620.6070000@cs.ucla.edu> <83mvt2qxm1.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> <567AD556.6020202@cs.ucla.edu> <567AD766.3060608@dancol.org> <567B5DAB.2000900@cs.ucla.edu> <83fuyromig.fsf@gnu.org> <567C25B1.3020101@dancol.org> <56892FD6.8040708@dancol.org> <56894CE7.7090301@cs.ucla.edu> <8337uea8ix.fsf@gnu.org> <568958D8.5060505@dancol.org> <83ziwm8sv2.fsf@gnu.org> <56895F0F.3050904@dancol.org> <83wprq8riy.fsf@gnu.org> <5689675A.70500@dancol.org> <83twmu8pjj.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f43KTlkRCcwECRuG439taMorb4UP6WPpA" X-Trace: ger.gmane.org 1451847871 31551 80.91.229.3 (3 Jan 2016 19:04:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 19:04:31 +0000 (UTC) Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 20:04:23 2016 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 1aFnwz-0003fJ-Ud for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 20:04:22 +0100 Original-Received: from localhost ([::1]:42567 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFnwz-0007sR-4y for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 14:04:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFnwv-0007sI-Jr for Emacs-devel@gnu.org; Sun, 03 Jan 2016 14:04:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFnws-0006BG-Cs for Emacs-devel@gnu.org; Sun, 03 Jan 2016 14:04:17 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:39186) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFnws-0006B8-1c; Sun, 03 Jan 2016 14:04:14 -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=hcqg170egbXTsWfhSO/2SF3w4EYCQ09N57F6z8eIMkc=; b=DiabPXU9rCFGdyOkc5vekssrDliPM1Fn6JenA6XIGyR/x8QA0v0/x4YmmaGaMowqPBC9vhk0X+6bS/6vKPU5UwRWFg3PJWvjS8hc51sK8DUOLWvvtXzad/UodeF8ulwwzD2Rcllcy2IRhFcoTZ2y63XlDI9T85zdaXvWiLW6bC2GGIPNPX1CgoP88PiP1/9dtRrBra8utDxnmehLbElFZR5NZ5g62Ma1aBNEiMRFfVNT4YCItpofh1UPp5XDQU4tRQN7WwEAOOI7qrUuHzc447CKia5R44djrBpR4erMKRoM+sxfudBRwnCeQcPRWVwUOU2yZ0IVcIMMbmErTjMZQA==; Original-Received: from c-67-161-115-4.hsd1.wa.comcast.net ([67.161.115.4] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aFnwq-0006b8-He; Sun, 03 Jan 2016 11:04:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <83twmu8pjj.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:197485 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f43KTlkRCcwECRuG439taMorb4UP6WPpA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/2016 10:51 AM, Eli Zaretskii wrote: >> Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Sun, 3 Jan 2016 10:24:26 -0800 >> >>> Robustness comes at a price. You are asking Emacs and its users to >>> pay a heavy price that they don't need to pay, because there are no >>> requirements for Emacs to be as robust as safety-critical software. >> >> It's not a heavy price at all. >=20 > Yes, it is. You would like us to crash rather than try recovering. > That is a very heavy price in Emacs. Why is it uniquely unacceptable in Emacs? Why do other programs that fill the same niche not employ this strategy? Why do we not try to mitigate NULL pointer dereferences (to which all the same arguments apply= )? You haven't addressed any of these points. >>> Only if you think about Emacs as safety-critical piece of software >>> that must operate continuously, 24x7. Otherwise, memory leaks when >>> recovering from a disaster that happens very rarely is quite >>> acceptable, if it brings other benefits (such as not losing work). >> >> My point isn't that memory leaks are disastrous. It's that the >> consequences of this code weren't given due consideration at the time = it >> was committed. >=20 > You have absolutely no evidence that this wasn't considered. It's > factually incorrect. You don't have to know that it's incorrect, but > I would expect you to give more credit to our collective knowledge and > experience than you evidently do. I searched the mailing list and saw no discussion of the points I raised. The rebuttals to my concerns ("so what if some memory leaks?", "emacs has longjmped from arbitrary points forever") have been inadequate and incorrect. >>> You are not objective, so you exaggerate the risks and dismiss the >>> benefits. >> >> I disagree that there *are* significant benefits. >=20 > Of course, you do. Like I said: your bias affects your judgment. So does yours. >=20 >>>> *Anything* can happen, and there's no guarantee that what happens is= >>>> better for the user than an immediate crash. Hell, you can even caus= e >>>> security problems with schemes of this sort. >>> >>> Sorry, that's FUD. >> >> No it isn't. When you invoke undefined behavior, anything unpleasant c= an >> happen, and at scale, everything unpleasant will. >=20 > It's not undefined behavior, not in practice. We know quite well what > can and cannot happen. No you don't, because we can longjmp out of third-party code, and unless you have a crystal ball, you're not going to be able to predict everything that code can do. That we know what can happen here is simply false. >=20 > Anyway, saying that "unpleasant things can happen" _is_ FUD. I want > to see a single bug report about these unpleasant things happening in > real use, then I'll start thinking whether I should reconsider. And I want to see a real bug report about the stack overflow we're trying to defend against. The failure mode here wouldn't be obvious either: Emacs could just silently crash, hang, or write a wrong byte or two to a file. You have no idea what might happen, which is especially concerning because Emacs is frequently an internet-facing network program parsing untrusted data. --f43KTlkRCcwECRuG439taMorb4UP6WPpA 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 iQIcBAEBCAAGBQJWiXCoAAoJEN4WImmbpWBlvhkP/2wecMp4AJBgALFnBdQ0bPGG t6LbCj9Rt90N9MblpcGk0YZS6bVtVD4V0wBtg7hpE06SslYuo7Y1jRZAzR39lIoa W5Ehn2R0J/f8EaTe6awkFDKTbTticSaSOC5NBCF4fFgiD10Zck+YrDZeuAF+TXzR jKTACt3+1TYarwfUoNGDuQnx7xyI6XTdn9elw5tL2KRtr6asFxznpxLTra++73La UX03iseztydYsjHuW7DdkIhUmOUvfR6EJXxiUbs6PlQTK3Yg1jBByWpOHqBFhWBa rzS3nrNsICwiFvTNpqVFK9epx8qABxU6y+QcXb8TQkFnp1K7hOsdUdnuaawcxffy it8IXWh4Ty9l0Pg/xBARy3Z9joxwH09T7eDyspZNEfuy+IS9cvzITWWW0yEQBcoe KNBcH9kjFmB/8npY73hE6NJ2JeVrJm/KTewfhRfDLVdg/8EiJ6qLVT9YGUFVCkNI 5nuosxEkbh8z0vtP3ffcTYGkGEATtHmaruMT0IgBXSrG50sl26jAWG2+lPKUTEz2 04eU8qeVKUw8d2waxYOYfi1Da6ymRehCFUmjWl+LTnjcCbXqour0nB7PnCdRPBqx dGPiyoiQusldyFtItsxfJdgh38vA9chgNGD2lbuJBoKCzC86WGJK3SyNG/cjByFG LWJnDacHotCDnE5mRQqS =kdHw -----END PGP SIGNATURE----- --f43KTlkRCcwECRuG439taMorb4UP6WPpA--