From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Sun, 03 Jan 2016 19:39:45 +0200 Message-ID: <83ziwm8sv2.fsf@gnu.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1451842800 21817 80.91.229.3 (3 Jan 2016 17:40:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 17:40:00 +0000 (UTC) Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 18:39:55 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 1aFmdG-0007Fx-Dr for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 18:39:54 +0100 Original-Received: from localhost ([::1]:42400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmdF-00076i-Ex for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 12:39:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmdC-00076Q-HA for Emacs-devel@gnu.org; Sun, 03 Jan 2016 12:39:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFmd9-0005dJ-BP for Emacs-devel@gnu.org; Sun, 03 Jan 2016 12:39:50 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFmd9-0005dE-8W; Sun, 03 Jan 2016 12:39:47 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2505 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aFmd7-0005nL-4R; Sun, 03 Jan 2016 12:39:45 -0500 In-reply-to: <568958D8.5060505@dancol.org> (message from Daniel Colascione on Sun, 3 Jan 2016 09:22:32 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:197473 Archived-At: > 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 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. 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 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. 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? > 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. We are not looking for safe techniques. That's exactly your mistake. We are looking for pragmatically helpful techniques.