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 14:09:41 +0200 Message-ID: <83pm9gzu2i.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> <16ecbe9ea8ba9d39d058@heytings.org> <16ecbe9ea85b22d008fd@heytings.org> <43460d2c-ba80-0f2f-656c-ef0aca5667b5@daniel-mendler.de> <87v8j84zp1.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11492"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, michael_heerdegen@web.de, mail@daniel-mendler.de, gregory@heytings.org, monnier@iro.umontreal.ca, 62009@debbugs.gnu.org To: Augusto Stoffel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 10 13:11:18 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 1pabaf-0002kV-RD for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Mar 2023 13:11:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pabaV-0003AH-9e; Fri, 10 Mar 2023 07:11: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 1pabaS-00039c-LU for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2023 07:11:05 -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 1pabaQ-0003zv-8X for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2023 07:11:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pabaQ-0005aS-4f for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2023 07:11: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 12:11: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.167845020721398 (code B ref 62009); Fri, 10 Mar 2023 12:11:02 +0000 Original-Received: (at 62009) by debbugs.gnu.org; 10 Mar 2023 12:10:07 +0000 Original-Received: from localhost ([127.0.0.1]:53946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pabZX-0005Z4-FF for submit@debbugs.gnu.org; Fri, 10 Mar 2023 07:10:07 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pabZV-0005Xu-E6 for 62009@debbugs.gnu.org; Fri, 10 Mar 2023 07:10:06 -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 1pabZP-0003XU-Bp; Fri, 10 Mar 2023 07:09:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=QNPwb3hS4u60incqkxSCtOp+/TwTOjyKvBbRH3hx8Tw=; b=IbX0aVOp5MPOLST13ucl gL1UNiN+7aVfPcFcmkiLjvBI0RQj+I9MxNMwSFEFthLZfLNEGPDbz3xQhCanhumh6BbvqOckY4o4R q2742w0gb9/unUpuHbJFF/2ss9G822CIDqrYWy0ALkY9RtR3qKspp8HPELbew2lSKi4X1yk0BPC7g Ox7gk5UsGgb9w4LtQOs1t1g1kYZxINuqOlxtEx5eoFjzE9/7A3oOZrc9+UcdLVJd+B37gpFur2snl 6f4s2R+aTUORAhdf0oK5kWv7l7vpao4286VLXhhC4sJp30N9+lKl3vqT3/ZhrPIbKlitANy4fbI7Q HYYBfGpiYlYyYQ==; 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 1pabZO-0008De-ST; Fri, 10 Mar 2023 07:09:59 -0500 In-Reply-To: <87v8j84zp1.fsf@gmail.com> (message from Augusto Stoffel on Fri, 10 Mar 2023 12:23:54 +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:257685 Archived-At: > From: Augusto Stoffel > Cc: Gregory Heytings , Eli Zaretskii , > Philip Kaludercic , michael_heerdegen@web.de, > monnier@iro.umontreal.ca, 62009@debbugs.gnu.org > Date: Fri, 10 Mar 2023 12:23:54 +0100 > > On Fri, 10 Mar 2023 at 12:09, Daniel Mendler wrote: > > > On 3/10/23 11:59, Gregory Heytings wrote: > >> That would also come with a performance overhead, as there is currently no > >> way to distinguist strings that are used for symbol names from other > >> strings. Not to mention the added complexity in the code. > > > > One could check if the string is located in read-only memory. Or one > > could add a flag bit to the string data structure (and possibly to other > > data structures too). Freezing data structures such that they become > > read-only is a generally useful feature. There won't be any performance > > overhead of the check since a branch not taken is fast thanks to the > > branch predictor. > > Note also that in-place modification of strings is arbitrarily costly, > cf. (aset "ascii" 0 ?😼). Not to mention that it's rarely a good or > necessary move to make, as far as programming style is concerned. Be this tru as it may, we will not constrain what Lisp programs can legitimately do just because we think it is "rarely a good move". That's against our long-time policy, which is explain why something might not be a good idea, but otherwise don't block that, letting the unwise cope with the consequences of their unwise actions. IOW, we encourage Lisp programmers to DTRT and not use dangerous practices, but don't block them if they want to.