GNU bug report logs - #7145
elisp-code behaves differently after byte-compilation

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7145 in the body.
You can then email your comments to 7145 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Markus Sauermann" <mhoram <at> gmx.de>
To: bug-gnu-emacs <at> gnu.org
Subject: elisp-code behaves differently after byte-compilation
Date: Sat, 02 Oct 2010 03:53:49 +0200

Hi,

I understand that byte-compiled code should do the same as the
uncompiled code (besides the macro-expansion problematic)

The following code however shows a case where this is not the case.

--- BEGIN CODE ---
(let ((fun (lambda () (let ((bar "foo")
                            (baz "foo"))
                        (eq bar baz)))))
  (list (funcall (byte-compile fun))
        (funcall fun)))
--- END CODE---

Evaluation this code (don't try to byte-compile it, because it is buggy ;-) ) results in:

--- BEGIN OUTPUT ---
(t nil)
--- END OUTPUT ---

which clearly means the byte compiation is somewhat broken.  It seems
during compilation the two strings "foo" are treated as the same
string.

Regards
Markus

-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Message #8 received at 7145 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: "Markus Sauermann" <mhoram <at> gmx.de>
Cc: 7145 <at> debbugs.gnu.org
Subject: Re: bug#7145: elisp-code behaves differently after byte-compilation
Date: Sat, 02 Oct 2010 10:54:47 +0200

"Markus Sauermann" <mhoram <at> gmx.de> writes:

> The following code however shows a case where this is not the case.
>
> --- BEGIN CODE ---
> (let ((fun (lambda () (let ((bar "foo")
>                             (baz "foo"))
>                         (eq bar baz)))))
>   (list (funcall (byte-compile fun))
>         (funcall fun)))
> --- END CODE---
>
> Evaluation this code (don't try to byte-compile it, because it is buggy ;-) ) results in:
>
> --- BEGIN OUTPUT ---
> (t nil)
> --- END OUTPUT ---

This is not a bug.  You cannot depend on the uniqueness of literal
strings.  If you want to compare strings you should use equal.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #11 received at 7145 <at> debbugs.gnu.org (full text, mbox):

From: Johan Bockgård <bojohan <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Markus Sauermann <mhoram <at> gmx.de>, 7145 <at> debbugs.gnu.org
Subject: Re: bug#7145: elisp-code behaves differently after byte-compilation
Date: Sat, 02 Oct 2010 12:41:18 +0200

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> "Markus Sauermann" <mhoram <at> gmx.de> writes:
>
>> The following code however shows a case where this is not the case.
>>
>> --- BEGIN CODE ---
>> (let ((fun (lambda () (let ((bar "foo")
>>                             (baz "foo"))
>>                         (eq bar baz)))))
>>   (list (funcall (byte-compile fun))
>>         (funcall fun)))
>> --- END CODE---
>>
>> Evaluation this code (don't try to byte-compile it, because it is buggy ;-) ) results in:
>>
>> --- BEGIN OUTPUT ---
>> (t nil)
>> --- END OUTPUT ---
>
> This is not a bug.

But this is, IMO:

(progn
  (defsubst spooky-action-at-a-distance ()
    (let ((a (concat "a" "bc")))
      (store-substring a 0 "123")))

  (defun foo ()
    (spooky-action-at-a-distance)
    (concat "ab" "c"))

  (byte-compile 'foo)
  (foo))

=>  "123"

Message #14 received at 7145 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Markus Sauermann <mhoram <at> gmx.de>, 7145 <at> debbugs.gnu.org
Subject: Re: bug#7145: elisp-code behaves differently after byte-compilation
Date: Sun, 03 Oct 2010 01:12:53 -0400

Johan Bockgård <bojohan <at> gnu.org> writes:

> But this is, IMO:
>
> (progn
>   (defsubst spooky-action-at-a-distance ()
>     (let ((a (concat "a" "bc")))
>       (store-substring a 0 "123")))
>
>   (defun foo ()
>     (spooky-action-at-a-distance)
>     (concat "ab" "c"))
>
>   (byte-compile 'foo)
>   (foo))
>
> =>  "123"

I think we're just going to have to ask people not to do that...

Message #17 received at 7145 <at> debbugs.gnu.org (full text, mbox):

From: Markus Sauermann <mhoram <at> gmx.de>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7145 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#7145: elisp-code behaves differently after byte-compilation
Date: Tue, 05 Oct 2010 19:37:03 +0200

Hi,

Am 03.10.2010 07:12, schrieb Chong Yidong:
> 
> I think we're just going to have to ask people not to do that...
> 

it looks like an undocumented feature ;-)
Here is a suggestion for a patch for the documentation (trunk of emacs
Bazaar repository)

--- BEGIN ---
=== modified file 'doc/lispref/objects.texi'
--- doc/lispref/objects.texi	2010-08-19 23:23:13 +0000
+++ doc/lispref/objects.texi	2010-10-05 18:00:58 +0000
@@ -1999,6 +1999,17 @@
      @result{} nil
 @end group
 @end example
+
+Be aware that byte-compiling a comparison of strings with @code{eq}
+might give unexpected results.
+
+@example
+@group
+(funcall (byte-compile (lambda () (let ((foo "bar"))
+                                    (eq foo "bar")))))
+     @result{} t
+@end group
+@end example
 @end defun

 @defun equal object1 object2

--- END ---

Regards
Markus

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.