From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62009: 29.0.60; Emacs crashes on setf symbol-name Date: Fri, 10 Mar 2023 17:02:41 +0200 Message-ID: <837cvozm26.fsf@gnu.org> 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> <5f5642f8-a8da-c002-4531-d102a119539f@daniel-mendler.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31687"; 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: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 10 16:04:22 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 1paeI9-0007wN-KO for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Mar 2023 16:04:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paeHu-00053v-C7; Fri, 10 Mar 2023 10:04:06 -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 1paeHq-00053c-MK for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2023 10:04:02 -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 1paeHq-0007O8-An for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2023 10:04:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1paeHq-0004pS-6C for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2023 10:04:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Mar 2023 15:04: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.167846058818487 (code B ref 62009); Fri, 10 Mar 2023 15:04:02 +0000 Original-Received: (at 62009) by debbugs.gnu.org; 10 Mar 2023 15:03:08 +0000 Original-Received: from localhost ([127.0.0.1]:55523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paeGx-0004o7-UH for submit@debbugs.gnu.org; Fri, 10 Mar 2023 10:03:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paeGw-0004ne-Fl for 62009@debbugs.gnu.org; Fri, 10 Mar 2023 10:03:07 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paeGq-00079q-9t; Fri, 10 Mar 2023 10:03:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=MMOsDKTrSgMTS2h80SHePVBUnR3KTCS2wVF1zhOKsq0=; b=C6ONRRGElzI3 lLGSX3mZ8oJUYsfFDOsljvSjheZOUXAusWgRRXupi6Ko/JfSC5QVaavaoaBGsjvx9XbrMHqFEmY2i V8pMWcLr5bochrPeorbXpFFcV/CoCo55ZuDuOHINmUvzYsNPCPiyP97Th93lPw3f0UpZdoPVu9kzi zL2o/Sp1V6f0WOqXh1b1pGsGV1L0vO5tAoHmv/35y7B7/cOau3K/7fuTdMKmHCG2xAxMUJGoldeCJ BRsmL8+vHYZDeg1soH1I+ETO+WAmYHCaZn9JCAqqevlvog96PuoSnWCHIxRRQGdurlAltHwRa9qmZ hViK7bx3PET8HBSLT85zPQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paeGp-0007KW-Jo; Fri, 10 Mar 2023 10:02:59 -0500 In-Reply-To: <5f5642f8-a8da-c002-4531-d102a119539f@daniel-mendler.de> (message from Daniel Mendler on Fri, 10 Mar 2023 14:08:44 +0100) 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:257700 Archived-At: > Date: Fri, 10 Mar 2023 14:08:44 +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 > > >> (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. I don't agree with "easily". And I think "not common" is an understatement. > This is a general question - do we want to prevent and catch most > programmer mistakes or not? Depends on the mistakes and the price. > 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. We disagree about the importance of the mistake, and we disagree about the costs of handling it. In addition to the runtime costs, in terms of CPU and memory/GC, there's also the aspect of introducing into Emacs a feature that we will have to support for the observable future. What if we want at some point to change how these strings are store, and that change makes these mistakes even harder to support? We are taking upon ourselves an obligation that we could regret, for the benefit of silly code that shouldn't be written in the first place. That kind of trade-off makes no sense. > 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. The disagreement is not about principles, it's about this particular case. > >> 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. That's your conclusion, not something I said. What I did say is that the nature and the rarity of the issue do not justify the costs.