GNU bug report logs - #40693
28.0.50; json-encode-alist changes alist

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: darthandrus <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 40693-done <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#40693: 28.0.50; json-encode-alist changes alist
Date: Fri, 22 May 2020 21:14:20 +0100

"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:

>> Am I missing something or doesn't this work like you want?
>
> There's a problem with the conditional require at byte-compile time.  If
> the version of Emacs doing the byte-compilation has native JSON support,
> then it will generate invalid byte-code (and complain) for the case
> where there is no native JSON support.  In other words, there will be a
> bug when an Emacs without native JSON loads a file that was
> byte-compiled in an Emacs with native JSON.

This doesn't give any any warning:

    (defvar foo-42 42)
     
    (provide 'foo)
    ;; foo.el ends here

and a bar.el

    (eval-and-compile
      (defvar bar-have-native-42 t) ;; or nil
     
      (unless bar-have-native-42 
        (require 'foo)))
     
    (defalias 'forty-two
      (if (eval-when-compile bar-have-native-42)
          (lambda () (message "%s" 42.0))
        (lambda () (message "%s" foo-42))))
    ;; bar.el ends here

And it seems to work in both cases:

     ~/tmp ❯❯❯ emacs -Q --batch -L . -f batch-byte-compile bar.el
     ~/tmp ❯❯❯ emacs -Q --batch -L . -l bar.elc -f forty-two
     42.0
     # now change that t to nil
     ~/tmp ❯❯❯ emacs -Q --batch -L . -f batch-byte-compile bar.el
     ~/tmp ❯❯❯ emacs -Q --batch -L . -l bar.elc -f forty-two
     42

But indeed in the recipe I gave you, I had forgotten the second
eval-when-compile.  If you take that away, it warns again.

No idea how to check if byte-code is "valid" or not: I just check the
warnings.  Can you tell me?

> Thanks.  I've therefore gone with the original patch[1], as it exhibits
> correct behaviour and is the least intrusive, but you should obviously
> feel free to tweak it as you prefer.

I think I'll let it be, the reason I'm not a huge fan is the foward
declarations of individual functions and variables, but it's not so bad.

João

Previous Next

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