GNU bug report logs - #31718
26.1; Strange behavior of `cond'

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 31718 in the body.
You can then email your comments to 31718 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: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; Strange behavior of `cond'
Date: Tue, 05 Jun 2018 15:26:02 +0900

The special form `cond' does not return expected value under a specific
condition.

[How to reproduce]
1. Save the following file as /tmp/test.el
---- test.el ---------------------------------------------------------
(defun xyz (arg)
  "dummy"
;    (cond ((eq arg nil) ; OK
;    (cond ((eq arg 'abc) ; OK
;    (cond ((eq arg 'def) ; OK
    (cond ((eq arg 'default) ; NG
;    (cond ((eq arg 'default1) ; OK
	   "A")
	  (t
	   "B")))

(byte-compile 'xyz)

(insert (xyz t)) ; should "B", but "A" in actual
----------------------------------------------------------------------
2. emacs-26.1 -Q -l /tmp/test.el
3. Expected result:
   "B" is inserted in *scratch*
   Actual result:
   "A" is inserted in *scratch*

[Some notes related to this issue]
a. As the comments written in the above code, only the symbol `default'
   triggers this behavior.
b. Emacs 25.3 doesn't have this problem.
c. If `xyz' is not byte compiled, `cond' works as expected.
d. It seems that the following entry in NEWS is related:
** Certain cond/pcase/cl-case forms are now compiled using a faster jump
table implementation.  This uses a new bytecode op 'switch', which
isn't compatible with previous Emacs versions.  This functionality can
be disabled by setting 'byte-compile-cond-use-jump-table' to nil.
   If I replace the line `(byte-compile 'xyz)' with
(let ((byte-compile-cond-use-jump-table nil))
  (byte-compile 'xyz))
   in the above example, `cond' works as expected.


In GNU Emacs 26.1 (build 1, x86_64-unknown-freebsd11.1, GTK+ Version 3.22.29)
 of 2018-05-30 built on freebsd.vmware
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
Recent messages:
Saving file /home/keita/Mail/drafts/1...
Wrote /home/keita/Mail/drafts/1
next-line: End of buffer [2 times]
Saving file /home/keita/Mail/drafts/1...
Wrote /home/keita/Mail/drafts/1
next-line: End of buffer [4 times]
Sending...backgrounded
Scanning +drafts...done
No messages in +drafts, range (all)
Quit [2 times]
user-error: No cross-references in this node
Configured using:
 'configure --with-canna --with-canna-includes=/usr/local/canna/include
--with-canna-libraries=/usr/local/canna/lib --mandir=/usr/local/man
--without-xim --with-sound=yes --with-file-notification=yes
--disable-largefile --without-pop CFLAGS=-O3'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS NOTIFY ACL GNUTLS
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 THREADS LCMS2

Important settings:
  value of $EMACSLOADPATH: /home/keita/elisp:
  value of $LANG: ja_JP.eucJP
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: japanese-iso-8bit-unix

Major mode: Info

Minor modes in effect:
  TeX-PDF-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
~/elisp/preview hides /usr/local/share/emacs/site-lisp/auctex/preview
~/elisp/tex-buf hides /usr/local/share/emacs/site-lisp/auctex/tex-buf
~/elisp/tex hides /usr/local/share/emacs/site-lisp/auctex/tex
~/elisp/reftex-parse hides /usr/local/share/emacs/26.1/lisp/textmodes/reftex-parse

Features:
(shadow emacsbug latexenc supercite regi mh-identity mh-letter mh-comp
sendmail qp info view mh-alias multi-prompt smiley mm-archive mail-extr
mh-mime mh-gnus mh-show goto-addr gnus-cite gnus-art mm-uu mml2015
mm-view mml-smime smime dig mh-inc hl-line mh-tool-bar mh-seq mh-xface
mh-utils mh-folder which-func imenu mh-scan mh-e mh-compat mh-buffers
mh-loaddefs preview prv-emacs reftex-dcr reftex-auc reftex
reftex-loaddefs reftex-vars tex-fold tex-bar tex-buf toolbar-x
font-latex latex edmacro kmacro latex-flymake flymake-proc flymake
warnings thingatpt tex-ispell tex-style tex dbus crm tex-mode compile
shell misearch multi-isearch vc-dispatcher vc-hg org-archive skeleton
org-rmail org-mhe org-irc org-info org-gnus nnir gnus-sum gnus-group
gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc
nnoo gnus-spec gnus-int gnus-range message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader gnus-win gnus
nnheader gnus-util rmail rmail-loaddefs mail-utils wid-edit org-docview
doc-view image-mode dired dired-loaddefs org-bibtex bibtex org-bbdb
org-w3m org-element avl-tree generator org org-macro org-footnote
org-pcomplete pcomplete org-list org-faces org-entities noutline outline
easy-mmode org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob
ob-table ob-keys ob-exp ob-comint comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func cal-menu calendar
cal-loaddefs jka-compr cl-extra help-mode parse-time ucs-normalize json
map epa derived epg epg-config url-http tls gnutls url-auth mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc
puny seq twittering-mode easymenu advice url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse auth-source cl-seq eieio byte-opt bytecomp byte-compile cconv
eieio-core cl-macs gv eieio-loaddefs cl-loaddefs cl-lib password-cache
url-vars mailcap xml elec-pair w3m-load preview-latex auto-loads
tex-site canna-im time-date mule-util japan-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind kqueue lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 585780 62716)
 (symbols 48 43330 1)
 (miscs 40 1448 1041)
 (strings 32 118129 14954)
 (string-bytes 1 4152041)
 (vectors 16 71953)
 (vector-slots 8 1968759 71038)
 (floats 8 346 479)
 (intervals 56 6509 2189)
 (buffers 992 42))

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

From: Andreas Schwab <schwab <at> suse.de>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 31718 <at> debbugs.gnu.org, Vibhav Pant <vibhavp <at> gmail.com>
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Tue, 05 Jun 2018 10:07:49 +0200

On Jun 05 2018, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:

> (defun xyz (arg)
>   "dummy"
> ;    (cond ((eq arg nil) ; OK
> ;    (cond ((eq arg 'abc) ; OK
> ;    (cond ((eq arg 'def) ; OK
>     (cond ((eq arg 'default) ; NG

The byte-compiler uses 'default as a magic symbol, which breaks this
case.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 31718 <at> debbugs.gnu.org, Vibhav Pant <vibhavp <at> gmail.com>
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Wed, 06 Jun 2018 14:41:55 +0900

Hi Andreas, thanks for your reply.

>>>>> Andreas Schwab <schwab <at> suse.de> writes:
> On Jun 05 2018, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:
>> (defun xyz (arg)
>> "dummy"
>> ;    (cond ((eq arg nil) ; OK
>> ;    (cond ((eq arg 'abc) ; OK
>> ;    (cond ((eq arg 'def) ; OK
>> (cond ((eq arg 'default) ; NG

> The byte-compiler uses 'default as a magic symbol, which breaks this
> case.

Does this mean that this behavior is a (new) designed feature of elisp
and not a bug?
If so, is it the respoisibility of the authors of the codes to rewrite
not to use `default' or else to make sure to set
`byte-compile-cond-use-jump-table' to nil at byte compile?

Best regards,
Ikumi Keita

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

From: Robert Cochran <robert-emacs <at> cochranmail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: Andreas Schwab <schwab <at> suse.de>, 31718 <at> debbugs.gnu.org,
 Vibhav Pant <vibhavp <at> gmail.com>
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Wed, 06 Jun 2018 00:41:50 -0700

[Message part 1 (text/plain, inline)]

Ikumi Keita <ikumi <at> ikumi.que.jp> writes:

> Hi Andreas, thanks for your reply.
>
>>>>>> Andreas Schwab <schwab <at> suse.de> writes:
>> On Jun 05 2018, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:
>>> (defun xyz (arg)
>>> "dummy"
>>> ;    (cond ((eq arg nil) ; OK
>>> ;    (cond ((eq arg 'abc) ; OK
>>> ;    (cond ((eq arg 'def) ; OK
>>> (cond ((eq arg 'default) ; NG
>
>> The byte-compiler uses 'default as a magic symbol, which breaks this
>> case.
>
> Does this mean that this behavior is a (new) designed feature of elisp
> and not a bug?
> If so, is it the respoisibility of the authors of the codes to rewrite
> not to use `default' or else to make sure to set
> `byte-compile-cond-use-jump-table' to nil at byte compile?

I for one consider this a bug, for 2 reasons:

1) It's not reasonable to expect a Lisp programmer to just know that
using the symbol default is problematic.

2) It creates diverging behavior between compiled and non-compiled Lisp.

To that end, I've made a small patch to rectify the behavior. Instead of
hardcoding a symbol, it uses gensym to create a unique one. I did a full
build of Emacs, as well as ran 'make check' and had identical results
pre- and post-change, so I'm reasonably sure it's correct.

Comments and corrections are of course welcomed.

HTH,
-- 
~Robert Cochran

GPG Fingerprint - BD0C 5F8B 381C 64F0 F3CE  E7B9 EC9A 872C 41B2 77C2

-----

[0001-Use-a-gensym-for-the-default-case-in-byte-compile-co.patch (text/x-patch, inline)]

From 4a025170b2b293810cf03c964b402963495fe7d7 Mon Sep 17 00:00:00 2001
From: Robert Cochran <robert-git <at> cochranmail.com>
Date: Wed, 6 Jun 2018 00:31:25 -0700
Subject: [PATCH] Use a gensym for the default case in
 byte-compile-cond-jump-table

* lisp/bytecomp.el (byte-compile-cond-jump-table): Create gensym to
  use as default case symbol
  (byte-compile-cond-jump-table-info): new argument `default-sym'; use
  it when generating default case clause
---
 lisp/emacs-lisp/bytecomp.el | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index ad6b5b7ce2..0fedfd0868 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -4092,7 +4092,7 @@ byte-compile-cond-vars
    (and (symbolp obj1) (macroexp-const-p obj2) (cons obj1 obj2))
    (and (symbolp obj2) (macroexp-const-p obj1) (cons obj2 obj1))))
 
-(defun byte-compile-cond-jump-table-info (clauses)
+(defun byte-compile-cond-jump-table-info (clauses default-sym)
   "If CLAUSES is a `cond' form where:
 The condition for each clause is of the form (TEST VAR VALUE).
 VAR is a variable.
@@ -4124,14 +4124,15 @@ byte-compile-cond-jump-table-info
                         (not (assq obj2 cases)))
                    (push (list (if (consp obj2) (eval obj2) obj2) body) cases)
                  (if (and (macroexp-const-p condition) condition)
-                     (progn (push (list 'default (or body `(,condition))) cases)
+                     (progn (push (list default-sym (or body `(,condition))) cases)
                             (throw 'break t))
                    (setq ok nil)
                    (throw 'break nil))))))
          (list (cons prev-test prev-var) (nreverse cases)))))
 
 (defun byte-compile-cond-jump-table (clauses)
-  (let* ((table-info (byte-compile-cond-jump-table-info clauses))
+  (let* ((default-sym (gensym "byte-compile--cond-default-sym"))
+         (table-info (byte-compile-cond-jump-table-info clauses default-sym))
          (test (caar table-info))
          (var (cdar table-info))
          (cases (cadr table-info))
@@ -4141,7 +4142,7 @@ byte-compile-cond-jump-table
       ;; set it to `t' for cond forms with a small number of cases.
       (setq jump-table (make-hash-table :test test
                                         :purecopy t
-                                        :size (if (assq 'default cases)
+                                        :size (if (assq default-sym cases)
                                                   (1- (length cases))
                                                 (length cases)))
             default-tag (byte-compile-make-tag)
@@ -4175,8 +4176,8 @@ byte-compile-cond-jump-table
       (let ((byte-compile-depth byte-compile-depth))
         (byte-compile-goto 'byte-goto default-tag))
 
-      (when (assq 'default cases)
-        (setq default-case (cadr (assq 'default cases))
+      (when (assq default-sym cases)
+        (setq default-case (cadr (assq default-sym cases))
               cases (butlast cases 1)))
 
       (dolist (case cases)
-- 
2.17.1

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

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Robert Cochran <robert-emacs <at> cochranmail.com>
Cc: Andreas Schwab <schwab <at> suse.de>, 31718 <at> debbugs.gnu.org,
 Vibhav Pant <vibhavp <at> gmail.com>
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Wed, 06 Jun 2018 18:14:03 +0900

Hi Robert,

>>>>> Robert Cochran <robert-emacs <at> cochranmail.com> writes:
> Ikumi Keita <ikumi <at> ikumi.que.jp> writes:
>> Hi Andreas, thanks for your reply.
>> 
>>>>>>> Andreas Schwab <schwab <at> suse.de> writes:
>>> On Jun 05 2018, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:
>>>> (defun xyz (arg)
>>>> "dummy"
>>>> ;    (cond ((eq arg nil) ; OK
>>>> ;    (cond ((eq arg 'abc) ; OK
>>>> ;    (cond ((eq arg 'def) ; OK
>>>> (cond ((eq arg 'default) ; NG
>> 
>>> The byte-compiler uses 'default as a magic symbol, which breaks this
>>> case.
>> 
>> Does this mean that this behavior is a (new) designed feature of elisp
>> and not a bug?
>> If so, is it the respoisibility of the authors of the codes to rewrite
>> not to use `default' or else to make sure to set
>> `byte-compile-cond-use-jump-table' to nil at byte compile?

> I for one consider this a bug, for 2 reasons:

> 1) It's not reasonable to expect a Lisp programmer to just know that
> using the symbol default is problematic.

> 2) It creates diverging behavior between compiled and non-compiled Lisp.

I agree.

> To that end, I've made a small patch to rectify the behavior. Instead of
> hardcoding a symbol, it uses gensym to create a unique one. I did a full
> build of Emacs, as well as ran 'make check' and had identical results
> pre- and post-change, so I'm reasonably sure it's correct.

Thanks for the patch, it fixes the problem on my side!

Regards,
Ikumi Keita

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

From: Robert Cochran <robert-emacs <at> cochranmail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: Andreas Schwab <schwab <at> suse.de>, 31718 <at> debbugs.gnu.org,
 Robert Cochran <robert-emacs <at> cochranmail.com>, Vibhav Pant <vibhavp <at> gmail.com>
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Mon, 11 Jun 2018 18:34:52 -0700

tags 31718 patch
quit

(I can do this as a mere luser, right? Moreover, did I DTRT?)

Ikumi Keita <ikumi <at> ikumi.que.jp> writes:

> Thanks for the patch, it fixes the problem on my side!

Good to hear! To that end, I'm going to (try to) mark the bug as 'patch
available'.

Also, thanks to Andreas for providing the key hint that made this change
much easier than would have been for me. Basically pointing me straight
to what I needed to look for was invaluable. :)

HTH, 
-- 
~Robert Cochran

GPG Fingerprint - BD0C 5F8B 381C 64F0 F3CE  E7B9 EC9A 872C 41B2 77C2

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Robert Cochran <robert-emacs <at> cochranmail.com>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>, 31718 <at> debbugs.gnu.org,
 Vibhav Pant <vibhavp <at> gmail.com>, Andreas Schwab <schwab <at> suse.de>
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Tue, 12 Jun 2018 18:22:01 -0400

tags 31718 + patch
quit

Robert Cochran <robert-emacs <at> cochranmail.com> writes:

> tags 31718 patch
> quit
>
> (I can do this as a mere luser, right? Moreover, did I DTRT?)

Yes, and not quite.  You need to send those lines to
control <at> debbugs.gnu.org.  When doing it as part of a mailing list
thread, you should use Bcc to avoid having other people's replies also
go to control.  That's why do you don't see that address when I do it.
See https://debbugs.gnu.org/server-control.html for more info.

Anyway, the patch looks good, I think it should go to emacs-26 as it's
solving a pretty important regression.  I will push there in a couple of
days, assuming no objections.

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

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Noam Postavsky <npostavs <at> gmail.com>,
 Robert Cochran <robert-emacs <at> cochranmail.com>
Cc: Andreas Schwab <schwab <at> suse.de>, 31718 <at> debbugs.gnu.org,
 Vibhav Pant <vibhavp <at> gmail.com>
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Wed, 13 Jun 2018 14:51:23 +0900

Hi Noam and Robert,

>>>>> Noam Postavsky <npostavs <at> gmail.com> writes:

> Anyway, the patch looks good, I think it should go to emacs-26 as it's
> solving a pretty important regression.

That's a good news, thanks.

> I will push there in a couple of days, assuming no objections.

As a minor issue, I suppose the doc string of
`byte-compile-cond-jump-table-info' should include mention about a new
argument `default-sym'.

Regards,
Ikumi Keita

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

From: Vibhav Pant <vibhavp <at> gmail.com>
To: ikumi <at> ikumi.que.jp
Cc: schwab <at> suse.de, 31718 <at> debbugs.gnu.org, robert-emacs <at> cochranmail.com,
 npostavs <at> gmail.com
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Wed, 13 Jun 2018 11:56:52 +0530

Hi,

Sorry for the late reply, this entire thread was somehow going into my
spam folder, and I didn't notice it until today.

The patch looks good to go, adding a doc-string for parameter
DEFAULT-SYM should be sufficient.

Thanks,
Vibhav

On Wed, Jun 13, 2018 at 11:21 AM Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:
>
> Hi Noam and Robert,
>
> >>>>> Noam Postavsky <npostavs <at> gmail.com> writes:
>
> > Anyway, the patch looks good, I think it should go to emacs-26 as it's
> > solving a pretty important regression.
>
> That's a good news, thanks.
>
> > I will push there in a couple of days, assuming no objections.
>
> As a minor issue, I suppose the doc string of
> `byte-compile-cond-jump-table-info' should include mention about a new
> argument `default-sym'.
>
> Regards,
> Ikumi Keita



-- 
Vibhav Pant
vibhavp <at> gmail.com

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Robert Cochran <robert-emacs <at> cochranmail.com>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>,
 Pierre Téchoueyres <pierre.techoueyres <at> free.fr>,
 Noam Postavsky <npostavs <at> gmail.com>, 31718 <at> debbugs.gnu.org,
 "Basil L. Contovounesios" <contovob <at> tcd.ie>, Jay Kamat <jaygkamat <at> gmail.com>,
 Vibhav Pant <vibhavp <at> gmail.com>, Andreas Schwab <schwab <at> suse.de>,
 Eli Zaretskii <eliz <at> gnu.org>,
 Héctor Enríquez Ramón <hector.e.r <at> gmail.com>
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Sat, 16 Jun 2018 08:10:02 -0700

[Message part 1 (text/plain, inline)]

Robert, thanks for your June 6 patch in Bug#31718#14. A small problem: gensym 
does not guarantee that the resulting symbol is unique, so the generated symbol 
could in theory appear in the input which would trigger the bug. Instead, let's 
use a guaranteed-unique object (cons nil nil). Also, I wrote a test case for 
this bug.

I installed the attached patch into the master branch. Given the practical 
consequences of this bug I expect the bug fix should be backported into the 
emacs-26 branch too.

[0001-Fix-byte-compilation-of-eq-foo-default.txt (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: robert-emacs <at> cochranmail.com, jaygkamat <at> gmail.com, ikumi <at> ikumi.que.jp,
 pierre.techoueyres <at> free.fr, npostavs <at> gmail.com, vibhavp <at> gmail.com,
 contovob <at> tcd.ie, 31718 <at> debbugs.gnu.org, schwab <at> suse.de, hector.e.r <at> gmail.com
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Sat, 16 Jun 2018 18:20:43 +0300

> Cc: 31718 <at> debbugs.gnu.org, Ikumi Keita <ikumi <at> ikumi.que.jp>,
>  Vibhav Pant <vibhavp <at> gmail.com>, Noam Postavsky <npostavs <at> gmail.com>,
>  Andreas Schwab <schwab <at> suse.de>, Jay Kamat <jaygkamat <at> gmail.com>,
>  Eli Zaretskii <eliz <at> gnu.org>, Pierre Téchoueyres
>  <pierre.techoueyres <at> free.fr>, Héctor Enríquez Ramón
>  <hector.e.r <at> gmail.com>, "Basil L. Contovounesios" <contovob <at> tcd.ie>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 16 Jun 2018 08:10:02 -0700
> 
> Given the practical consequences of this bug I expect the bug fix
> should be backported into the emacs-26 branch too.

Could you explain why?  I'm not necessarily opposed, but AFAIU this
was Emacs's behavior since day one, so it isn't a recent regression.
Am I mistaken?

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Robert Cochran <robert-emacs <at> cochranmail.com>,
 Jay Kamat <jaygkamat <at> gmail.com>, Ikumi Keita <ikumi <at> ikumi.que.jp>,
 Héctor Enríquez Ramón <hector.e.r <at> gmail.com>,
 Vibhav Pant <vibhavp <at> gmail.com>, "Basil L.
 Contovounesios" <contovob <at> tcd.ie>, 31718 <at> debbugs.gnu.org,
 Pierre Téchoueyres <pierre.techoueyres <at> free.fr>,
 Andreas Schwab <schwab <at> suse.de>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Sat, 16 Jun 2018 11:23:33 -0400

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> A small problem: gensym does not guarantee that the resulting symbol
> is unique so the generated symbol could in theory appear in the input

What?

    gensym is a compiled Lisp function in ‘subr.el’.

    (gensym &optional PREFIX)

    Return a new uninterned symbol.
             ^^^

How could a new symbol have already appeared in the input?

(I have no objection to the alternative you used, just wondering why
gensym is not also correct)

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: robert-emacs <at> cochranmail.com, jaygkamat <at> gmail.com, ikumi <at> ikumi.que.jp,
 pierre.techoueyres <at> free.fr, npostavs <at> gmail.com, vibhavp <at> gmail.com,
 contovob <at> tcd.ie, 31718 <at> debbugs.gnu.org, schwab <at> suse.de, hector.e.r <at> gmail.com
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Sat, 16 Jun 2018 08:28:57 -0700

Eli Zaretskii wrote:
>> Given the practical consequences of this bug I expect the bug fix
>> should be backported into the emacs-26 branch too.
> Could you explain why?

We've had three independent reports of the bug (Bug#28806, Bug#31718, 
Bug#31734), I expect because org-mode triggers the Emacs bug. Bug#28806#5 says 
it occurs with Emacs 26 but not Emacs 25. Bug#31718#5 says it occurs with Emacs 
26 but not Emacs 25.3. So the bug is a regression, and it's biting real users.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Robert Cochran <robert-emacs <at> cochranmail.com>,
 Jay Kamat <jaygkamat <at> gmail.com>, Ikumi Keita <ikumi <at> ikumi.que.jp>,
 Héctor Enríquez Ramón <hector.e.r <at> gmail.com>,
 Vibhav Pant <vibhavp <at> gmail.com>, "Basil L. Contovounesios" <contovob <at> tcd.ie>,
 31718 <at> debbugs.gnu.org,
 Pierre Téchoueyres <pierre.techoueyres <at> free.fr>,
 Andreas Schwab <schwab <at> suse.de>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Sat, 16 Jun 2018 08:30:34 -0700

Noam Postavsky wrote:
>      Return a new uninterned symbol.

You're right, my mistake. Still, I prefer using (cons nil nil) since it's 
cheaper and is a common way to address this issue elsewhere.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: robert-emacs <at> cochranmail.com, jaygkamat <at> gmail.com, ikumi <at> ikumi.que.jp,
 pierre.techoueyres <at> free.fr, npostavs <at> gmail.com, vibhavp <at> gmail.com,
 contovob <at> tcd.ie, 31718 <at> debbugs.gnu.org, schwab <at> suse.de, hector.e.r <at> gmail.com
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Sat, 16 Jun 2018 19:02:05 +0300

> Cc: robert-emacs <at> cochranmail.com, 31718 <at> debbugs.gnu.org, ikumi <at> ikumi.que.jp,
>  vibhavp <at> gmail.com, npostavs <at> gmail.com, schwab <at> suse.de, jaygkamat <at> gmail.com,
>  pierre.techoueyres <at> free.fr, hector.e.r <at> gmail.com, contovob <at> tcd.ie
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 16 Jun 2018 08:28:57 -0700
> 
> Eli Zaretskii wrote:
> >> Given the practical consequences of this bug I expect the bug fix
> >> should be backported into the emacs-26 branch too.
> > Could you explain why?
> 
> We've had three independent reports of the bug (Bug#28806, Bug#31718, 
> Bug#31734), I expect because org-mode triggers the Emacs bug. Bug#28806#5 says 
> it occurs with Emacs 26 but not Emacs 25. Bug#31718#5 says it occurs with Emacs 
> 26 but not Emacs 25.3. So the bug is a regression, and it's biting real users.

If it's a regression, then let's backport, indeed.

Thanks.

Message #58 received at 31718-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: robert-emacs <at> cochranmail.com, 31718-done <at> debbugs.gnu.org, schwab <at> suse.de,
 pierre.techoueyres <at> free.fr, npostavs <at> gmail.com, vibhavp <at> gmail.com,
 contovob <at> tcd.ie, jaygkamat <at> gmail.com, ikumi <at> ikumi.que.jp, hector.e.r <at> gmail.com
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Sat, 16 Jun 2018 09:45:47 -0700

Eli Zaretskii wrote:
> If it's a regression, then let's backport, indeed.

OK, done, and closing the bug report.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Noam Postavsky <npostavs <at> gmail.com>
Cc: Robert Cochran <robert-emacs <at> cochranmail.com>,
 Ikumi Keita <ikumi <at> ikumi.que.jp>,
 Héctor Enríquez Ramón <hector.e.r <at> gmail.com>,
 Vibhav Pant <vibhavp <at> gmail.com>, "Basil L.
 Contovounesios" <contovob <at> tcd.ie>, Jay Kamat <jaygkamat <at> gmail.com>,
 Pierre Téchoueyres <pierre.techoueyres <at> free.fr>,
 Andreas Schwab <schwab <at> suse.de>, 31718 <at> debbugs.gnu.org
Subject: RE: bug#31718: 26.1; Strange behavior of `cond'
Date: Sat, 16 Jun 2018 16:00:52 -0700 (PDT)

> You're right, my mistake. Still, I prefer using (cons nil nil) since it's
> cheaper and is a common way to address this issue elsewhere.

Both ways are traditional, the cons-cell one being probably
more typical (and so more recognizable).

In any case, for such a (good, not bad) hack - either one,
a comment is always in order, I think.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Robert Cochran <robert-emacs <at> cochranmail.com>,
 Ikumi Keita <ikumi <at> ikumi.que.jp>,
 Pierre Téchoueyres <pierre.techoueyres <at> free.fr>,
 Noam Postavsky <npostavs <at> gmail.com>, Vibhav Pant <vibhavp <at> gmail.com>,
 "Basil L. Contovounesios" <contovob <at> tcd.ie>, Jay Kamat <jaygkamat <at> gmail.com>,
 Héctor Enríquez Ramón
 <hector.e.r <at> gmail.com>, Andreas Schwab <schwab <at> suse.de>, 31718 <at> debbugs.gnu.org
Subject: Re: bug#31718: 26.1; Strange behavior of `cond'
Date: Sun, 17 Jun 2018 06:44:00 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> Robert, thanks for your June 6 patch in Bug#31718#14. A small problem:
> gensym does not guarantee that the resulting symbol is unique

Really?  AFAIK the name is not guaranteed to be unique, but the returned
symbol is.


Michael.

Previous Next

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