From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.bugs Subject: bug#62009: 29.0.60; Emacs crashes on setf symbol-name Date: Fri, 10 Mar 2023 14:08:44 +0100 Message-ID: <5f5642f8-a8da-c002-4531-d102a119539f@daniel-mendler.de> References: <87o7p5of4n.fsf@daniel-mendler.de> <871qm01s6n.fsf@web.de> <9fcf05e8-506c-6566-e214-2ecf3194b85e@daniel-mendler.de> <83bkl45ul4.fsf@gnu.org> <87v8j9zl3i.fsf@posteo.net> <83a60l13p2.fsf@gnu.org> <87ilf9571k.fsf@gmail.com> <87edpx56xm.fsf@gmail.com> <83wn3ozuyn.fsf@gnu.org> <83h6uszsvq.fsf@gnu.org> <1cfd0b10-546e-c2c9-272a-25d3cdd4ba82@daniel-mendler.de> <83cz5gzruw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27158"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, michael_heerdegen@web.de, rpluim@gmail.com, monnier@iro.umontreal.ca, 62009@debbugs.gnu.org, arstoffel@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 10 14:09:15 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pacUl-0006ps-8C for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Mar 2023 14:09:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pacUc-0007o0-PQ; Fri, 10 Mar 2023 08:09:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pacUZ-0007gP-3J for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2023 08:09:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pacUY-0002KE-OT for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2023 08:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pacUY-000192-KE for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2023 08:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Mar 2023 13:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62009 X-GNU-PR-Package: emacs Original-Received: via spool by 62009-submit@debbugs.gnu.org id=B62009.16784537414385 (code B ref 62009); Fri, 10 Mar 2023 13:09:02 +0000 Original-Received: (at 62009) by debbugs.gnu.org; 10 Mar 2023 13:09:01 +0000 Original-Received: from localhost ([127.0.0.1]:54042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pacUS-00018T-AV for submit@debbugs.gnu.org; Fri, 10 Mar 2023 08:09:01 -0500 Original-Received: from server.qxqx.de ([178.63.65.180]:50893 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pacUP-00018F-VG for 62009@debbugs.gnu.org; Fri, 10 Mar 2023 08:08:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uJ1bog3BWsDgkpKLtKrhk1j6S3n4b/nQ2Lj6BaomCb4=; b=rFo66bp9fcMuwBsy+hpz0ESENJ RIfdD3L0W2cLC7/kQ1/9u2J97gnpO0cHCUfWPGmDHko7HU4Dm/Q+E0zZfcRwwSGOmDNOQ+nvaiUgw nc3JDD+/2hAgBOQtXAl/PYwRim1X6iSev+9bUvtk7uP0MvF/6M2cXm1AhbnLHxC2uP+E=; Content-Language: en-US In-Reply-To: <83cz5gzruw.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:257696 Archived-At: On 3/10/23 13:57, Eli Zaretskii wrote: >> Date: Fri, 10 Mar 2023 13:45:11 +0100 >> Cc: philipk@posteo.net, michael_heerdegen@web.de, monnier@iro.umontreal.ca, >> 62009@debbugs.gnu.org, rpluim@gmail.com, arstoffel@gmail.com >> From: Daniel Mendler >> >>> We disagree here, and this is a very fundamental disagreement, which >>> basically means continuing this argument is pointless, since we have >>> no common basis. >> >> I don't see that the disagreement is that strong. For example aset >> signals an error if you try to access elements out of bounds. >> >> (aset "abc" 3 ?x) -> args-out-of-range > > yes, because that's a frequent programmatic mistake. Agree. >> So there are clearly use cases where signaling an error is justified. > > Of course. It's just that the use case being discussed is not one of > them. I agree with you, that this is not a common mistake. But it is still a mistake and we could easily protect the user from it. This is a general question - do we want to prevent and catch most programmer mistakes or not? You seem to lean on rather not catching some errors which are rare and I am in favor of catching more errors if the costs permit. In this case, the costs are small in my book (I cannot look into your book and understand how you come to your conclusions). Given that Robert already pointed out that objects can be marked as read-only, all the necessary infrastructure is already in place, making this a cheap change. Catching more mistakes improves overall robustness of Emacs and generally there are also security considerations which should be taken into account. It may not matter in this case, but ensuring that the Elisp runtime is memory safe as much as possible is a worthy goal. >> In other cases you claim signaling an error is unjustified and a >> crash is better. > > I said nothing of the kind. I said it was unjustified in the > particular case which is being discussed here. You clearly said that you object to any measures which fix this issue. This means you prefer if Emacs crashes, instead of it signaling an error. Daniel