From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: 31395511: =?utf-8?Q?=22Don=E2=80=99t?= attempt to modify constant strings" Date: Fri, 05 Jun 2020 09:48:55 +0000 Message-ID: <87wo4l267s.fsf@gmail.com> References: <871rmvn7ge.fsf@gmail.com> <87lfl36abx.fsf@gmail.com> <1abe5965-b48e-6dee-1516-c5c233f09d01@cs.ucla.edu> <87d06f5m2c.fsf@gmail.com> <87lfl3f5mj.fsf@tcd.ie> <87k10m4l5v.fsf@gmail.com> <8e691d13-8db0-2066-8725-ea8afab7c506@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="20085"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: "Basil L. Contovounesios" , =?utf-8?B?Sm/Do28gVMOh?= =?utf-8?B?dm9yYQ==?= , emacs-devel To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 05 11:50:52 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jh900-00058h-Bv for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 11:50:52 +0200 Original-Received: from localhost ([::1]:37130 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jh8zz-0006kp-DA for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 05:50:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jh8yE-00039v-Hm for emacs-devel@gnu.org; Fri, 05 Jun 2020 05:49:02 -0400 Original-Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]:40323) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jh8yD-0006nL-F8 for emacs-devel@gnu.org; Fri, 05 Jun 2020 05:49:02 -0400 Original-Received: by mail-ej1-x636.google.com with SMTP id q19so9395801eja.7 for ; Fri, 05 Jun 2020 02:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=O/lrLvVeBEbcRUQPPb+gcMchjzGFFRGCeLlDEf65/d8=; b=LqLyo/V6ROY7PTl/JqFrovkKUeQWSaBO7ubsE+1U2Fj42cIEo3zF8M8RsejAo/28Y+ NRHoVGnJYTTRksb8BUzfE2u7mnHrBjSZ7O4FIsA15XtT6WkokhFogo3MEPoHjX4OaL1H 8u/YvVfYsNBCebnZi6zw2NLkJ5if/V0bMQebtv5GJ9+tU8zc3WPirOLdBeMGQIituzbP 5HPRZIbNIpUt+YOyfuGUxQ+Xz+S9TpnnLJAwTVb4s7bFJ6tzd/DBiSdFsWg0zQDGW+hr o39ZFc4Tffh8EKRdkI6gBiT/76jhlSs59HCMXrN5FZZ3OtrzvLNAaNlzji+XG41lY4xi o0PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=O/lrLvVeBEbcRUQPPb+gcMchjzGFFRGCeLlDEf65/d8=; b=q5/OPEoYdd8N0k1uYUGAm144eshmelsweVjuyNBOn9lIs/DvSOK6ejB/zNBoPxKwNU hSThAAVj9xnFDrUGY4dLpOOApW7nbUbtF7U+P7uJpBYWx0KU/d7U7OisnHBJyy/Rrh/m VpU9F0xUgrZTVaMDb/O9fpHvaZpNT6XM7og2SRihQfpRbNd8pvoQMITXG0P6O/BRrVTw utAFhQteYM6QLxlWgyuGkdNgD5SRMGVUZPiu7rcgVDxnvVpBHwcyfi6IHq6+xs7i6SzU yEwXvXCyKVvkxqsAkCxJjz6Y3jYcKHo9hVF81y7fYj7kbhM3xm5QSbCParwp997VuNrq vQ5g== X-Gm-Message-State: AOAM531v/OK9L8bJE4UkhHvzvNdU1bIWzy22fYAxjGi3aii4qQH/HcHA a+aPEN9NW7pAhnjWIylME/ooF6mOdoU= X-Google-Smtp-Source: ABdhPJyShhRJzZIol0VZbi7Zdr3MkLEcJLT7iixWCdCMtQm1+uURdzparIRzKEWO7uB3IKzBQEVL3Q== X-Received: by 2002:a17:906:49da:: with SMTP id w26mr7768767ejv.548.1591350539257; Fri, 05 Jun 2020 02:48:59 -0700 (PDT) Original-Received: from chametz ([31.220.2.134]) by smtp.gmail.com with ESMTPSA id bo26sm4550575edb.67.2020.06.05.02.48.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2020 02:48:58 -0700 (PDT) In-Reply-To: <8e691d13-8db0-2066-8725-ea8afab7c506@cs.ucla.edu> (Paul Eggert's message of "Thu, 4 Jun 2020 16:10:10 -0700") Received-SPF: pass client-ip=2a00:1450:4864:20::636; envelope-from=pipcet@gmail.com; helo=mail-ej1-x636.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251886 Archived-At: Paul Eggert writes: > On 6/4/20 1:43 PM, Pip Cet wrote: > >> I'd prefer a mutablep predicate, with a strong warning not >> to use it > > I'd rather not not build/support/advertise predicates that shouldn't > be used.... It's perfectly usable in most situations, it's just that you shouldn't use it to decide whether your function has side effects or not. >>> No such error is thrown now and Emacs can crash or worse - but I >>> plan to arrange for one to be thrown. >> >> Have those plans been discussed anywhere? I get the impression it would >> help me to understand what you're planning to do. > > A few weeks ago, a bit. The idea I have is pretty simple: the Emacs > interpreter > throws an error if you attempt to modify a string constant. Although the > interpreter done this for years, (a) its test for whether a string is > a constant > has always been spotty and (b) the test has gone downhill recently. I think there was only CHECK_IMPURE, which relies on PURE_P, which is effectively a nop in post-dump binaries. (I still think we should remove pure space entirely, but even if we don't we should stop wasting so much binary size on zeroes. But let's wait for Emacs 27 first, as Eli suggested). >> I fail to see how that code is broken: it uses an ephemeral string >> literal > > String literals are not ephemeral; I still believe this one is. It's used in a top-level form in a defvar. > they can be coalesced, or retained, or put into read-only memory. Really? Is there code in Emacs (other than purecopy, which isn't the problem here) that does any of that today? > And when Emacs does that your program's behavior becomes squirrelly. If Emacs were to, a lot of code would break, yes. IMHO, that's a good reason to leave things as they are for now, deal with the pure space issues first, and then decide whether immutable objects are worth it at all... >> (text-properties-at N STRING) returns the >> string's actual plist, so you can mutate it, which seems useless and >> potentially dangerous to me. (Please, let's change that?) > > We could do something along those lines eventually. The immediate problem that > I'm looking at is just the string itself. > >> Would you consider (text-properties-at N STRING) to be part of the >> string object itself, or an object it points at? > > My earlier email was assuming the current implementation, which is the latter. > However, I don't think this matters much, since string literals shouldn't have > text properties. But if text properties aren't part of "the string itself", they can be given text properties. >> Which undefined behavior is that, precisely? > > I was referring to code that modifies literal strings' contents or properties. > We don't really define how that works, and in practice it doesn't work the way > people might naively expect since strings might be coalesced and their > contents > might be in read-only memory. You're saying "in practice ... their contents might be in read-only memory"? How?