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: Re: master f51f963: Fix some side-effecting uses of make-text-button Date: Sat, 6 Jun 2020 13:15:35 -0700 Organization: UCLA Computer Science Department Message-ID: <785d730e-23b2-dcad-105c-80ac5074b5dc@cs.ucla.edu> References: <20200604223056.17078.81265@vcs0.savannah.gnu.org> <20200604223058.1850020A26@vcs0.savannah.gnu.org> <87eeqtiy4x.fsf@tcd.ie> <87img51y04.fsf@gmail.com> <5c66eeb5-a513-0443-4316-e41aae118677@cs.ucla.edu> <87img4zjy7.fsf@gmail.com> <1742051d-ff33-fe97-d0ee-83f55847d98a@cs.ucla.edu> <87lfl0x9qi.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="90935"; 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" , Stefan Monnier , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 06 22:16:16 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 1jhfEm-000Na9-0E for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 22:16:16 +0200 Original-Received: from localhost ([::1]:34406 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhfEl-0007gf-2A for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 16:16:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47036) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhfEE-00079S-9w for emacs-devel@gnu.org; Sat, 06 Jun 2020 16:15:42 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50192) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhfEC-0007RC-16 for emacs-devel@gnu.org; Sat, 06 Jun 2020 16:15:41 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 637E81600E0; Sat, 6 Jun 2020 13:15:37 -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 CS52IViT8j9x; Sat, 6 Jun 2020 13:15:36 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7FAEC1600E1; Sat, 6 Jun 2020 13:15:36 -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 dF_2DPrTMX4z; Sat, 6 Jun 2020 13:15:36 -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 3FD8B1600E0; Sat, 6 Jun 2020 13:15:36 -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: <87lfl0x9qi.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/06 13:54:51 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:251966 Archived-At: On 6/6/20 12:41 PM, Pip Cet wrote: > What I'm fighting against is a certain model of > immutability being installed into the Emacs source tree and effectively > preventing better ones from ever having a chance, as well as turning out > to be, as the vast majority of such models have, a problem rather than a > useful feature. I'm quite conscious of those dangers. What I had in mind was something far more limited: just supporting runtime checking of attempts to modify strings that either have undefined behavior if you mutate them now, or are close enough to that category so that nobody will care about the difference (except to be happy when Emacs catches unlikely glitches in their programs). In my drafts so far Emacs requires no more storage than it does now, and the CPU performance does not change significantly, so overall this change should be a win in practical use. It'd be a more-drastic change to add mutability/immutability as a more-general concept to Emacs, to add new functions that freeze or check the mutability status of arbitrary objects, etc., etc.. I'm not ready to propose that now and I don't know if it'd be a good idea. My goal right now is to prevent Emacs crashes and and general bugginess, not to add general mutability features. > I think you've essentially documented the changes > you're considering to propose as though they had already happened. No, I first discussed and wrote those changes in response to a bug report, and only later looked into conservative ways of fixing some of the real problems uncovered by that documentation effort. > if we want that C API to be flexible enough to allow unusual > applications (and isn't that what Emacs is all about?), it needs > something more than just the obvious CHECK_MUTABLE (obj) macro. It sounds like you're thinking ahead to the non-string case. I'm limiting myself just to strings for now, as they're the most salient part of the problem (core dumps and all). It should be OK to do that, and put off the more-general issues until later (if we ever do that at all). The obvious check_string_mutable function doesn't need to be used very often: only in the places where CHECK_IMPURE is used on strings now. The only other primitive I've found the need for at the C level is freeze_string (to mark an already-constructed string as being a constant).