bug#7145: elisp-code behaves differently after byte-compilation

bug#7145: elisp-code behaves differently after byte-compilation

[Markus Sauermann]

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

bug#7145: elisp-code behaves differently after byte-compilation

[Andreas Schwab]

"Markus Sauermann" <mhoram@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#7145: elisp-code behaves differently after byte-compilation

[Johan Bockgård]

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

> "Markus Sauermann" <mhoram@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"

bug#7145: elisp-code behaves differently after byte-compilation

[Chong Yidong]

Johan Bockgård <bojohan@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...

bug#7145: elisp-code behaves differently after byte-compilation

[Markus Sauermann]

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