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 10:24:26 -0800 Message-ID: <5689675A.70500@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5DmJrTUbLA22CXgUdXo5WmxKX9Wm2vtRb" X-Trace: ger.gmane.org 1451845492 29453 80.91.229.3 (3 Jan 2016 18:24:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 18:24:52 +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 19:24:47 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 1aFnKf-0007HH-SE for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 19:24:46 +0100 Original-Received: from localhost ([::1]:42487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFnKf-0001IP-4Y for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 13:24:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFnKb-0001IH-J0 for Emacs-devel@gnu.org; Sun, 03 Jan 2016 13:24:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFnKW-0007SM-4y for Emacs-devel@gnu.org; Sun, 03 Jan 2016 13:24:40 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:38936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFnKV-0007S2-RV; Sun, 03 Jan 2016 13:24:36 -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=aN5V+e2S60nK6QVI9owwDDYh3pBh4oNWSLZwqDmrgJY=; b=SKZiuiNJXRoLO1Dui9cawz7NTDiyvJul3qdDJIgILFbkG2KL6LE8YTxNVXO7wnRGiHgOWwCHMz6KHDcJjMcYasLxVVspQhGzVQIEh61aRV8Lvqn/pb2ObqNhHIxaWziU8x9bOSQBSg7nlVAcPfALJK3TP1QLrJKW8KeoUllxLwWez5sna6+vJqbFJjiLb0MmC8Dk57g8BwjtDxctAuKP1UmdQxAvDiBGZvf12oNNMmBxqT1YMhr5XElfZnCMjP1JLu41exaxuFlb5CoIZO3gkHjXUh4gJ4rQlnlBU5/J+hmNSHDWuWtBfXheBuEusVMEV8kw+gQN+ngM2ifp6HL9tg==; 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 1aFnKQ-0006Ok-Jm; Sun, 03 Jan 2016 10:24:30 -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: <83wprq8riy.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:197482 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5DmJrTUbLA22CXgUdXo5WmxKX9Wm2vtRb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/2016 10:08 AM, Eli Zaretskii wrote: >> 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 a= nd >>>> 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 fundamenta= l >>> 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. >=20 > 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. We already protect against runaway lisp code. If this stack overflow recovery were so important, you'd see other programs in the same niche (e.g., vim) do it. Why is Emacs alone here? > 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. >=20 >>>> 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 th= an >>>> the auto-save functionality and that makes it worth reaching for uns= afe >>>> 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 Emac= s >>> on their record, disagree with you constitute such an evidence? >> >> That's not evidence. It's the opinion of two people >=20 > The argument is about assessments. There could be no facts here, only > opinions. What else did you expect? >=20 >> 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. >=20 > 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. >>>> 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. >=20 > You are not objective, so you exaggerate the risks and dismiss the > benefits. I disagree that there *are* significant 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. >=20 > Sorry, that's FUD. No it isn't. When you invoke undefined behavior, anything unpleasant can happen, and at scale, everything unpleasant will. --5DmJrTUbLA22CXgUdXo5WmxKX9Wm2vtRb 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 iQIcBAEBCAAGBQJWiWdaAAoJEN4WImmbpWBl6B8P/AlTrBFkCJNQsvDqLFn+leHM 3OgK+VxFx75tKqwyX5q0znHb6L8xPIMBGB76jpWa8X5ds+5mozrRKRzifmSRb1r3 +kS2ex3QG2cM8bb+QCZKmyNtwPQTl23bPyWUeic8BIbmX9etOIh0WA4U23PX3kLK AHaVVVl+2xd4YqxWhp0fWo9+q1Ll9H0S9Jh2lTMm5dD15FLGq7fusoW1Q8ZInigu YgnVnlSLLZLaS8aLZ0hFHyidfxS+njnu/CiV+iEZmygUwQ7pZL9Hn5OW2bubxeLo hqR0OUwiVSBWred16MLkigbDXlWztHbQ4x6DerlfmYcmJJ8wdY5AUddXuv5J/Fpn qATD3rJkcehB9Eac7bITn7i6wUYGTcrGAT/oTMIUHhk2ryQh91qhsHEUAe2XWpyq maumLPn4aEjsARosSD7xgp4X0du8BLmjRYnGwhdXMn9xx10qLpceC/wLZexbiz+5 wZVq01RKWeEo0yUsFxBIWRA/AmAxZMN+iy7aGyH9icMjRgvroL0g+q8YjP0bQN/a gF75EkmTCWvcR6aW1iwgREx3sOJsEfLII6r8F7MVdHgD/7zMys1nzxX+U5ipUfNw SuyYN0d86dGKwGMH0mDUle+ajCD6hQ80aONJq3GhXBuzM0iwqSN25xR/YooT5p6T Je9nhfKesWoxpHGy+kRH =cWDN -----END PGP SIGNATURE----- --5DmJrTUbLA22CXgUdXo5WmxKX9Wm2vtRb--