GNU bug report logs - #57684
locked narrowing breaks existing code without an apparent way to repair

Previous Next

Package: emacs;

Reported by: Paul Pogonyshev <pogonyshev <at> gmail.com>

Date: Thu, 8 Sep 2022 19:38:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57684 <at> debbugs.gnu.org
Subject: bug#57684: locked narrowing breaks existing code without an apparent way to repair
Date: Thu, 15 Sep 2022 23:38:15 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Even if Elisp code is buggy, Emacs itself should never allow it to fall into an infinite loop and stop
  > > responding to C-g, leaving full restart as the only way out.

It used to be impossible to have an infinite loop in Emacs Lisp that
you could not quit out of.  The Lisp interpreter and tye bytecode
interpreter both had calls to QUIT in all the loops of Lisp execution.
Likewise, all the loops in C code that corresponded to Lisp loops, and
might fail to terminate if given circular lists, such as Fmemq,
had calls to QUIT.

If that is now no longertrue, what made it cease to be true?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






This bug report was last modified 2 years and 274 days ago.

Previous Next


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