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 20:08:37 +0200 Message-ID: <83wprq8riy.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> <83ziwm8sv2.fsf@gnu.org> <56895F0F.3050904@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1451844539 14847 80.91.229.3 (3 Jan 2016 18:08:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 18:08:59 +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 19:08:53 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 1aFn5I-0000ll-DA for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 19:08:52 +0100 Original-Received: from localhost ([::1]:42454 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFn5H-0005Lw-I5 for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 13:08:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFn56-0005Lo-ON for Emacs-devel@gnu.org; Sun, 03 Jan 2016 13:08:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFn53-0003xd-Hd for Emacs-devel@gnu.org; Sun, 03 Jan 2016 13:08:40 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFn53-0003xY-DW; Sun, 03 Jan 2016 13:08:37 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2527 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aFn52-0006Vp-IR; Sun, 03 Jan 2016 13:08:37 -0500 In-reply-to: <56895F0F.3050904@dancol.org> (message from Daniel Colascione on Sun, 3 Jan 2016 09:49:03 -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:197479 Archived-At: > Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org > From: Daniel Colascione > Date: Sun, 3 Jan 2016 09:49:03 -0800 > > >> 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'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. 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. Engineering is about compromises: you design and implement your systems to meet the requirements with some reasonable margin, but you do not implement non-essential features that exert a significant impact on what the product can or cannot do. Doing so is bad engineering. > >> 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? > > That's not evidence. It's the opinion of two people The argument is about assessments. There could be no facts here, only opinions. What else did you expect? > 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. 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). > >> 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. > > 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. You are not objective, so you exaggerate the risks and dismiss the benefits. > *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. Sorry, that's FUD.