From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: =?UTF-8?Q?Re=3a_31395511=3a_=22Don=e2=80=99t_attempt_to_modify_cons?= =?UTF-8?Q?tant_strings=22?= Date: Thu, 4 Jun 2020 16:10:10 -0700 Organization: UCLA Computer Science Department Message-ID: <8e691d13-8db0-2066-8725-ea8afab7c506@cs.ucla.edu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="3190"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: "Basil L. Contovounesios" , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , emacs-devel To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 05 01:11:02 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 1jgz0o-0000ig-JT for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 01:11:02 +0200 Original-Received: from localhost ([::1]:59388 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgz0n-0003xT-BN for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jun 2020 19:11:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44700) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgz04-0003K9-JC for emacs-devel@gnu.org; Thu, 04 Jun 2020 19:10:16 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52148) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgz02-0007iN-E0 for emacs-devel@gnu.org; Thu, 04 Jun 2020 19:10:15 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F0C231600C4; Thu, 4 Jun 2020 16:10:11 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id USGKL1xXnknW; Thu, 4 Jun 2020 16:10:11 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 18D4C1600DE; Thu, 4 Jun 2020 16:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SMmV5I2hr0q3; Thu, 4 Jun 2020 16:10:10 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D20191600C4; Thu, 4 Jun 2020 16:10:10 -0700 (PDT) Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoU In-Reply-To: <87k10m4l5v.fsf@gmail.com> Content-Language: en-US Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/04 19:10:12 X-ACL-Warn: Detected OS = Linux 3.1-3.10 X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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:251875 Archived-At: 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.... >> 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 fail to see how that code is broken: it uses an ephemeral string > literal String literals are not ephemeral; they can be coalesced, or retained, or put into read-only memory. And when Emacs does that your program's behavior becomes squirrelly. > Well, a documented return value would be a good start. The "BEG can be > a string, in which case it's really the object, and we'll return it" > thing is confusing, I think. Yup. > I would suggest two functions, one which propertizes a string to be a > button when inserted, and returns the propertized string; and one which > adds text properties to make a range of an object (string or buffer) > into a button, and doesn't return anything useful. I'm no expert on make-text-button etc. so I'll let the experts comment on that one. > (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. > 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.