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:49:03 -0800 Message-ID: <56895F0F.3050904@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="A4jCgSLPkEK2q4TAPgV2tt6tofO6WAp6g" X-Trace: ger.gmane.org 1451843367 29949 80.91.229.3 (3 Jan 2016 17:49:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 17:49:27 +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 18:49:21 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 1aFmmN-0007i9-UW for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 18:49:20 +0100 Original-Received: from localhost ([::1]:42414 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmmM-0000Vk-Ty for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 12:49:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmmI-0000VU-8S for Emacs-devel@gnu.org; Sun, 03 Jan 2016 12:49:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFmmD-0007n7-Bl for Emacs-devel@gnu.org; Sun, 03 Jan 2016 12:49:14 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:38765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmmC-0007mq-W7; Sun, 03 Jan 2016 12:49:09 -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=ojAWgURF/Xq7jnSmPYXDx0Xje7J69LUBXAGmypTawjQ=; b=ADrMwJNpaCeEQbqgdCEjnVCgRdN+PCkGXoDatgZT8lgpP3B7vB9EKvxne3xrwAFQqsGu18tVRK68ddqLT8YLA6hPSSf36gGUa5Huhv+qNug9ayb97IxaijzomJZKTq2EonMFBpWiIfp1lARCoOaiBvDHkx/AIe8s0ikRHW1GvVoITceWQIssOmKWJgMinB+80w1Tbi9YT04yw3XRwwrIKUkupOcJ2ByMXXSl6psm+3o3wxaNG8RA23OsS+NRf+X0CYdRHfPtE0JfzCB4ZbUGZSxW+1EXlT6tMBRRMqC09cPM4vQSk38dIl16gZTyfrHwJSs7gE/n2t30Ey7nY/6+jg==; 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 1aFmmB-0006DT-CE; Sun, 03 Jan 2016 09:49:07 -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: <83ziwm8sv2.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:197475 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A4jCgSLPkEK2q4TAPgV2tt6tofO6WAp6g Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/2016 09:39 AM, Eli Zaretskii wrote: >> Cc: Emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Sun, 3 Jan 2016 09:22:32 -0800 >> >>> IOW, a requirement as fundamental as safety-criticality _does_ affect= >>> the design and the techniques allowed during implementation. I submi= t >>> 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 nast= y >>> crash can be fatal, something that is very far from what Emacs can do= =2E >> >> 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 th= at >> add no real value and quite a bit of real danger. >=20 > It's not false dichotomy, it's real. That you misunderstand this > crucial issue is the root cause of this dispute and of our fundamental > disagreement. You are applying theory outside of its domain of > applicability. You're not seeing that robustness applies to all software, not just "safety-critical" (however you define that) software, because users depend on software being predictable. >> You have *still* not presented any evidence, not one shred, that we ha= ve >> a real stack overflow problem that makes it worth relying on more than= >> the auto-save functionality and that makes it worth reaching for unsaf= e >> and completely undefined behavior. >=20 > Not sure what evidence you are looking for. Does the fact that 2 not > entirely stupid Emacs developers, each one with years of hacking Emacs > on their record, disagree with you constitute such an evidence? That's not evidence. It's the opinion of two people, one of whom previously said that the worst side effect of this scheme is a potential memory leak, a statement that suggests that the dangers of this scheme are not being appreciated. >> 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. >=20 > We are not looking for safe techniques. That's exactly your mistake. > We are looking for pragmatically helpful techniques. I don't think this technique is even helpful. Quite the opposite, actually, if we start to pollute the module API with some facility for dealing with the result of this awful stack overflow scheme. The trouble with unsafe mitigations like this one (which inhabits the same robustness tier as "#define pthread_mutex_lock(l) (void)0 /*LOL FAST*/") is that errors compound, and once you let undefined behavior leak in somewhere, you can no longer reason about how the system operates. It's essential to kill and restart software as soon as you notice anything going wrong, because only then does reason still apply to the system. *Anything* can happen, and there's no guarantee that what happens is better for the user than an immediate crash. Hell, you can even cause security problems with schemes of this sort. --A4jCgSLPkEK2q4TAPgV2tt6tofO6WAp6g 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 iQIcBAEBCAAGBQJWiV8PAAoJEN4WImmbpWBl13QP+gNYERywY6iPHXrn2CxC7Zpt kJKysV0qsW4Gv6hx70kyBPLvRJM9nK8XnVnHIuAk8hGMSQ9JKo7ckgJeuCXHUV30 TaIvfIlP+nhnUO6q6Td6+cILGu+z40gz58E/RlADJjFbKDgf82Bvg/y1yfB8HFHz c7AVEBSr9+uHcE3XTPgC+R3AaOk+aAIdg3WNJHMgsLSPuLKqckCKRO8X0aVwQvua /boHnojRYTd4GVOzkBK7G2rsXBpaekEXU6ixy/0UaybtFprQpvb87Bhe+u2hUi93 2q9pxVTBZPH/Ex1EcGz+DSlBMVnh4k55FY5atTUhkXF9A4002qgfS0ojo4bd0QdO DtDffCDWYzKDRg8k4U1UXDrlIgCPUU21B7iKr6J3WjBFRr2zATgceQveCEXA0snq ruj42O+WKQLBPrVpmUXUJHOH2V/QKHCB7HxcfKYLSVg+lG5HENaBWrdtVPqqiGue x9lBQByMmjVq1OTIb2FJ4iTyZFQVrlSoEGste5oq2PvDIju5t6ELeMj+Gew/NYx3 VZpyxlpugAW3rWQUCDwVPUt1KeRleBHLkz2df80FLYCtdIaPKFkxBmeMcz48/yf/ wIoPk3+ieurIw0I5LnYWGGfRxJors7CBYZc39ikFJmzfiBqapg092TuyEqyHD3/Z r+oT9YB9oW4/iO5dqpTx =Toi6 -----END PGP SIGNATURE----- --A4jCgSLPkEK2q4TAPgV2tt6tofO6WAp6g--