From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#31688: 26.1.50; Byte compiler confuses two string variables Date: Mon, 04 Jun 2018 22:02:27 +1200 Message-ID: <2a9f684c2867ae9a7deccb51d04f9de6@webmail.orcon.net.nz> References: <87a7sdkrft.fsf@runbox.com> <87po199id0.fsf@gmail.com> <5c6b2383ccd9c7d9b4058d249274b8c4@webmail.orcon.net.nz> <87d0x8agn3.fsf@gmail.com> <389bb1de5df69b513db3097aa3e000cb@webmail.orcon.net.nz> <87y3fw9g18.fsf@igel.home> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1528106881 10035 195.159.176.226 (4 Jun 2018 10:08:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Jun 2018 10:08:01 +0000 (UTC) User-Agent: Orcon Webmail Cc: Gemini Lasswell , Noam Postavsky , bug-gnu-emacs , 31688@debbugs.gnu.org To: Andreas Schwab Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 04 12:07:56 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fPmP3-0002S4-UI for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Jun 2018 12:07:54 +0200 Original-Received: from localhost ([::1]:38683 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fPmRB-0002Bp-5M for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Jun 2018 06:10:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fPmKQ-0004ve-Rs for bug-gnu-emacs@gnu.org; Mon, 04 Jun 2018 06:03:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fPmKM-0004fF-2H for bug-gnu-emacs@gnu.org; Mon, 04 Jun 2018 06:03:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53004) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fPmKL-0004f7-V2 for bug-gnu-emacs@gnu.org; Mon, 04 Jun 2018 06:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fPmKL-0007Kq-Mo for bug-gnu-emacs@gnu.org; Mon, 04 Jun 2018 06:03:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Jun 2018 10:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31688 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31688-submit@debbugs.gnu.org id=B31688.152810656428168 (code B ref 31688); Mon, 04 Jun 2018 10:03:01 +0000 Original-Received: (at 31688) by debbugs.gnu.org; 4 Jun 2018 10:02:44 +0000 Original-Received: from localhost ([127.0.0.1]:60901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fPmK4-0007KF-1m for submit@debbugs.gnu.org; Mon, 04 Jun 2018 06:02:44 -0400 Original-Received: from smtp-3.orcon.net.nz ([60.234.4.44]:53798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fPmK1-0007K4-Mf for 31688@debbugs.gnu.org; Mon, 04 Jun 2018 06:02:42 -0400 Original-Received: from [10.253.37.70] (port=10346 helo=webmail.orcon.net.nz) by smtp-3.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1fPmJo-0004HX-1v; Mon, 04 Jun 2018 22:02:29 +1200 Original-Received: from [150.107.175.190] via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Mon, 04 Jun 2018 22:02:27 +1200 In-Reply-To: <87y3fw9g18.fsf@igel.home> X-Sender: psainty@orcon.net.nz X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:146944 Archived-At: On 2018-06-04 01:05, Andreas Schwab wrote: > On Jun 04 2018, Phil Sainty wrote: >> I generally dislike it when byte-compiled and interpreted code >> give different results. > > This really has nothing to do with byte-compilation. Whether > literals are shared or not should not be relied upon. You always > have to be careful when modifying values in-place. I don't disagree that one ought to take care when modifying values in-place, but my general concern is purely that the byte-compiler is producing code which does not behave the same as the uncompiled code. (i.e. I think my issue is specifically to do with byte-compilation, and I would consider such discrepancies to be a problem irrespective of the sort of code which was affected.) Surely consistent behaviour between compiled and uncompiled code is not only desirable, but a primary goal? I realise (albeit vaguely) that the byte code and its interpreter are rather different to the uncompiled versions, so I suppose this may not be the only situation where a discrepancy results; but I think that known cases ought be identified and documented (and I think that eliminating such differences may be a valuable improvement). The "(elisp)Byte Compilation" info node could certainly do with a child node detailing the ways in which byte-compiled code behaves differently from uncompiled code, so that elisp authors can gain an understanding of all these nuances from a single section of the manual. > Whether literals are shared or not should not be relied upon. Why? I mean, in this case we already know the answer, but why shouldn't the behaviour be consistent and dependable between the two variants? Again, it bothers me to think that someone could observe a bug when running byte-compiled code, and try to debug it but, through the process of instrumenting functions for debugging, unwittingly change the behaviour of the code such that the bug no longer occurs. -Phil