From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#40671: [DOC] modify literal objects Date: Mon, 27 Apr 2020 03:53:51 +0300 Message-ID: <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> References: <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="33986"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 27 02:55:12 2020 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 1jSs3D-0008fM-VU for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Apr 2020 02:55:12 +0200 Original-Received: from localhost ([::1]:49592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSs3C-0005iz-Ml for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 Apr 2020 20:55:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53336) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSs34-0005iq-SA for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 20:55:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSs34-0003JO-8z for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 20:55:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51934) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSs33-0003Hs-SA for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 20:55:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jSs33-0005ut-PX for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 20:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2020 00:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40671 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158794884222673 (code B ref 40671); Mon, 27 Apr 2020 00:55:01 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 27 Apr 2020 00:54:02 +0000 Original-Received: from localhost ([127.0.0.1]:35247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSs26-0005td-Ar for submit@debbugs.gnu.org; Sun, 26 Apr 2020 20:54:02 -0400 Original-Received: from mail-wr1-f42.google.com ([209.85.221.42]:46767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSs24-0005t9-6J for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 20:54:00 -0400 Original-Received: by mail-wr1-f42.google.com with SMTP id f13so18501483wrm.13 for <40671@debbugs.gnu.org>; Sun, 26 Apr 2020 17:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uJ5A03RahimetOFrSySQvXvhtKa7SYkqPm06eGl++0M=; b=cu67ZXSCm/XuLTE1USm2q/06e4rvdGo5T7Ewzu6jX+nZNnVN+it4IsBxrvXKT5DlQi Gg3CLoswP8894mmcVOVOoycoyTdwrf+WXBkxwhOWqZaKcGhnDVimsLWDm9hrygW0cJvT tytuvJwHePCXudBk/QdCrL4KsQ6TOku0hWYi2kQ2g1R3K0bH2iaMm2akV1tN6FKTk7N8 ZWi512OulHyLxttpakg7Uu3PcLDvc2K2okp4OmxCTlSj+uiMyFLUzboh0SNSjlazc2jj jzhN1/iVmQqGaM7oIKgxqawuoJOYuYKKetHv5dtZTAUKrowLHBL+LTRhdpmTmWPSITuL Mspg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uJ5A03RahimetOFrSySQvXvhtKa7SYkqPm06eGl++0M=; b=AOoJbhmKL9TGUAMYRguY9Ft7C4Pssa+AND0nxNLceUrns2PDuTvp94kQ1wrHO3t5b7 o0DuupeBbcKjolzknGJJOkfPd82BKWawoBlpz2U8j2poDdCUuY8YFVdQEDa9uwEOqjrV qZQRn1UTZs4BC6g7B1idDwKm05CubWk2lI98ci5pJi98TdmVZy/bt4iWbNyXzCH+8gEf GtDZhilCODREXVHKC/HPALKHNIUWCjH9pCZNdCXYnJpeGTVkclEh8ny1+BOh833zrSxx gl78xpkoKsIDNKDMqMEbOf8K5Gg7xWZbqmEiTrPCN0GUBkNhhESlUMpPp526xN/fSEGq yqYw== X-Gm-Message-State: AGi0PuafhfvHp8R3mO7HnIvxDej0we8iUBBrr7vl5tAmxjZLBC7lwYPh 1/ukHGVVgtdp/m3zlT5f8tU= X-Google-Smtp-Source: APiQypK/QQZB1qc8H85v202ATpexanFcvnjud4PDBLDTtTQL2kYb9I+qyXQp8PGU/NkYwobcQYJRsQ== X-Received: by 2002:a5d:4e12:: with SMTP id p18mr24969890wrt.148.1587948834238; Sun, 26 Apr 2020 17:53:54 -0700 (PDT) Original-Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id q187sm13495940wma.41.2020.04.26.17.53.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Apr 2020 17:53:53 -0700 (PDT) In-Reply-To: <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Received-From: 209.51.188.43 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" Xref: news.gmane.io gmane.emacs.bugs:179118 Archived-At: On 27.04.2020 02:13, Paul Eggert wrote: >> This just illustrates a weakness of type system in C/C++. The same way you could >> pass a string into a function that expects an int. > > Although it's a weakness, it's different from the char * vs int weakness. It's > well-defined in C that one can cast char * to char const * and back without > trouble. The same is not true for casting char * to int and back. This compiles fine: #include int main (void) { return !strcpy ((char*)2, "b"); } My point is, it's hard to discuss static typing guarantees when type casting is involved. >> is it undefined? > > Yes, it's undefined. C11 section 6.7.3 paragraph 6 says, "If an attempt is made > to modify an object defined with a const-qualified type through use of an lvalue > with non-const-qualified type, the behavior is undefined." Sorry if that was unclear. I mean, is the behavior of "literal objects" in Emacs Lisp undefined when one tries to modify them? >> Do you have an example of a version of Emacs where this behavior was different? > > Emacs 26. Sorry, I don't have an Emacs 26 at hand. Should 25 suffice? Just tried this in IELM: ELISP> (setq a '(1 . 2)) (1 . 2) ELISP> (setcdr a 3) 3 (#o3, #x3, ?\C-c) ELISP> a (1 . 3) ELISP> emacs-version "25.2.3" >>> Unfortunately, the relevant code is hairy and any fixes certainly won't happen >>> before the Emacs 27 release. In the meantime it's better to warn users clearly >>> about the gotchas in this area, to help prevent some of the confusion >>> exemplified by Bug#40671. >> >> Perhaps you meant some other bug report? > > No, the original bug report that started this thread illustrates some of the > confusion in this area. Okay, yes. I though you had a bug report with a description of a practical problem. >> In all of my experience, the term "constant" is usually applied to names >> (variables), or pointers. And it almost always means that you're not allowed to >> change it. Or if you are, you can't do it by accident. > > Unfortunately that experience does not apply to C and to other low-level > languages. Even Java once allowed programs to modify "constants" by using > reflection, though recent Java versions have fixed this. Hence the last sentence of my paragraph you quoted. In Ruby, we also have "constants" and we sometimes laugh about being able to change them. And yet, there also you can't do it by accident. >> The previous term "literal objects", however, seems accurate enough > > We could use any term we like, and if there's consensus for using the term > "literal object" instead of "constant" then we can redo the manual that way. > However, the problem can occur with strings that were never string literals in > any source-code Elisp program. And a Elisp string can begin its life as a > mutable string and then become a "constant" (or "literal object") later. So it's > not clear that the longer phrase is less confusing. "A mutable string can become a constant later and yet remain modifiable in practice" sounds really confusing. We better warn against modifying any values that are part of a "literal object" anywhere.