GNU bug report logs -
#67116
byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference.
Previous Next
Reported by: Alan Mackenzie <acm <at> muc.de>
Date: Sat, 11 Nov 2023 22:50:01 UTC
Severity: normal
Done: Mattias EngdegÄrd <mattias.engdegard <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello, Emacs.
Emacs master branch.
In lisp/emacs-lisp/bytecomp.el (byte-compile-let), when the following
form (from jit-lock--debug-fontify):
(let
((beg pos)
(end (setq pos
(next-single-property-change
pos 'fontified
nil (point-max)))))
(put-text-property beg end 'fontified nil)
(jit-lock-fontify-now beg end))
gets byte compiled, the order of evaluating BEG and END gets reversed so
that END gets evaluated first. Since the value for END contains (setq
pos ...), BEG gets this updated value of POS rather then the original
intended value.
This particular bug in jit-lock.el can be fixed by using let* rather
than let, but this isn't the point. I believe (without testing) that
the interpreted code for the form would evaluate BEG before END, hence
testing it interpreted (e.g. under edebug) will give a false sense of
correctness.
The comment in byte-compile-let:
;; Bind the variables.
;; For `let', do it in reverse order, because it makes no
;; semantic difference, but it is a lot more efficient since the
;; values are now in reverse order on the stack.
, is not true. It can make a semantic difference. So doing the binding
in reverse order is a bug.
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 1 year and 245 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.