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 09:22:32 -0800 Message-ID: <568958D8.5060505@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j971gsDh81gkMJOLIVHcHmS0JOplPw4cr" X-Trace: ger.gmane.org 1451841777 6825 80.91.229.3 (3 Jan 2016 17:22:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 17:22:57 +0000 (UTC) Cc: Emacs-devel@gnu.org To: Eli Zaretskii , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 18:22:49 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 1aFmMi-0007Vd-KH for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 18:22:48 +0100 Original-Received: from localhost ([::1]:42370 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmMh-0003YV-Ox for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 12:22:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmMd-0003YK-7M for Emacs-devel@gnu.org; Sun, 03 Jan 2016 12:22:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFmMY-0001wP-BV for Emacs-devel@gnu.org; Sun, 03 Jan 2016 12:22:43 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:38599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmMY-0001wL-0e; Sun, 03 Jan 2016 12:22:38 -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=7mIDJ6Ct7cHcd5r0UzZTC+stEQoOtkrn9gY6D1qbGx4=; b=Zt4hQBbmOZx9z0JLv5m0b/D/Rzp2gOktcYk/Zbol82rG5OSV8T6ZGzhGMPFI4RaJ9NFduyKiDTiHHfmn2lM03njqwKQLVE/80eoUGcaySKmCUpVmGSjHr9pPkw5J3h8Ynd9YN/RSYWaqqwdrRi7RhlZNuJk6TM+J4iZbmDhmvYEJMMBn812vKuL+IOdGlFLBUGgnxOC19OQB8U+Bw1eCtpEX4ML/SYtPPY5/p3TFXH8dVc8Ta1uGXN7oujcvj6f97hlDW25Q64Cwegu0mxZ1tiYrXFMR+4Y+rNBm+5zthCh0MUSrKNgU2hkgiycsFPzxTUTUOlTlUcq8lDGE5StFIg==; 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 1aFmMX-00065B-48; Sun, 03 Jan 2016 09:22:37 -0800 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <8337uea8ix.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:197471 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j971gsDh81gkMJOLIVHcHmS0JOplPw4cr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/2016 09:16 AM, Eli Zaretskii wrote: >> From: Paul Eggert >> Date: Sun, 3 Jan 2016 08:31:35 -0800 >> >> Daniel Colascione wrote: >>> In 2014, Emacs gained a new path in the SIGSEGV handler that attempts= to >>> detect C stack oerflow and longjmp back to toplevel. It's important t= o >>> note that we don't just longjmp when we're in a safe position: we >>> longjmp from *anywhere*, even if we're, say, in the middle of malloc.= >> >> Although that particular code path may have been introduced recently, = for=20 >> decades Emacs has longjmped from arbitrary locations due to other sign= als, so=20 >> adding a longjmp for SIGSEGV does not introduce new issues. >> >>> The code is fundamentally flawed and cannot be made to work >>> properly on any platform. >> >> The code is part of Emacs 24.5 and does not appear to be causing probl= ems; at=20 >> least, I don't recall any bug reports from the field. The other longjm= ps, which=20 >> are fundamentally flawed in the same way, have been in Emacs for decad= es, and=20 >> also seem to work well enough in practice. >=20 > All true. Untrue. Which jumps in particular can come from inside malloc? > But we are reiterating a long discussion, where all of this was > already said, and said again, and again, and again. There's nothing > new left to be said here. >=20 > Daniel thinks that Emacs should be designed and implemented as > safety-critical software, where any such techniques are a definite > no-no. But Emacs is not a safety-critical program, it is allowed to > crash from time to time, even in nasty ways. It is therefore okay for > such a program to use techniques that make the probability of losing > work lower. My analysis of this discussion is that this is the > crucial point that Daniel refuses to understand and/or agree to -- > that being a non safety-critical piece of software means Emacs can do > stuff that it otherwise would have been prohibited from doing. It's not about whether Emacs is "safety critical" --- it's about whether you're making the robustness situation worse than it already is by adding dubious workarounds for a problem we don't actually have. The Linux kernel doesn't bill itself as safety critical either, and this kind of reckless sloppiness wouldn't be acceptable there either. > IOW, a requirement as fundamental as safety-criticality _does_ affect > the design and the techniques allowed during implementation. I submit > that this is a fundamental software engineering issue which cannot be > cast away, and as long as Daniel misinterprets it, we can never agree > on anything. Because in safety-critical software, even a single nasty > crash can be fatal, something that is very far from what Emacs can do. You're creating a false dichotomy between safety-critical software and everything else. Emacs merely not avionics-grade software does not excuse the use of techniques that are both inherently incorrect and that add no real value and quite a bit of real danger. You have *still* not presented any evidence, not one shred, that we have a real stack overflow problem that makes it worth relying on more than the auto-save functionality and that makes it worth reaching for unsafe and completely undefined behavior. All you have is your assertion that Emacs is not safety-critical software, we can should use this technique, which you have not demonstrated saves anyone anything and which I have demonstrated is completely unsafe. --j971gsDh81gkMJOLIVHcHmS0JOplPw4cr 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 iQIcBAEBCAAGBQJWiVjYAAoJEN4WImmbpWBlVE0P/j01TVlHfT4KF1KbOwE3gy91 q5FwDS07Aua3zgQ1rT1aosIjJWoSRrPkfyr768T5yL3b2QCTaPSAZkz3DvS+V50U bj9c8Z8gGM4wTheTDnd9NS9mTojbxA/ckRy2ICHOoR8CgEFnT5sE4v39bIY4g321 8P6H6WFUyB42WgcZ21aT6GavG4Y72jVyNAxM6Rrj7pf+vkgBTQ0zm056+Big///i dXmCTODeHAI00ouOQyYQMkIX5q8xHMyhH+joBkNkSE5Gy8NUHgRATCKYhRqV3hU7 wCmFk931sZITVRcYdP4fsYYJELZbfFz251SyY+T/vlqJvogaOFw3MZY6TGiTXJBi iZQrZ9M1lSmrpq65Y0vHw02dWhQEAQiTXHib0swIiYK4GOK0LYi7aGw7qp1z3xjY tpEELWw4NPGD2JCz4yybh8NR3FBvengh8A2Or7N1O4+cP0C9IhBith1/r2t3BjhH RzBkS5xbsrL4uW0Blizju4nBth9TWpTwnq1qpyN7dm3cUAUbDOAJjguRN6nvRdeJ BNFG5IImpOF+wuqgkrzqijsB9SXie8hhIuz6WMytqEIXrWBdErDAu0op6xMPZTIQ dalWS3ZH8AvzcF+igRif4LgedTOLJdgyOQAMdJIE0UamwQPTYGbn1AMQY3jSUw4c kv9glfJAIRBXqFUHXDyr =H5BO -----END PGP SIGNATURE----- --j971gsDh81gkMJOLIVHcHmS0JOplPw4cr--