GNU bug report logs - #103
23.0.60; Segmentation fault loading auto-lang.el

Previous Next

Package: emacs;

Reported by: intrigeri <intrigeri <at> boum.org>

Date: Sun, 30 Mar 2008 22:15:12 UTC

Severity: normal

Done: Chong Yidong <cyd <at> stupidchicken.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Kenichi Handa <handa <at> m17n.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: emacs-devel <at> gnu.org, intrigeri <at> boum.org, 103 <at> debbugs.gnu.org
Subject: bug#103: 23.0.60; Segmentation fault loading auto-lang.el
Date: Tue, 08 Apr 2008 15:52:27 +0900
In article <87r6dg3oe2.fsf <at> stupidchicken.com>, Chong Yidong <cyd <at> stupidchicken.com> writes:

> > - download http://www.marquardt-home.de/auto-lang.el to ~/.elisp/
> > - run emacs -Q
> > - M-x load-file
> > - choose file ~/.elisp/auto-lang.el
> > => Emacs segfaults (same result with emacs -Q -nw)

> This is due to an infinite nesting depth in regexp-opt, which can be
> tracked down to the following problem:

> (let ((str (string-as-unibyte "$(D+#(B")))
>   (string-match (char-to-string (string-to-char str)) str))

> evaluates to 0 in Emacs 22, and to nil in Emacs 23.  It turns out that
> this screws up the use of all-completions in regexp-opt-group.

> Anyone have any idea what's going on here?

(string-as-unibyte "$(D+#(B") => "\303\244"
(string-to-char "\303\244") => 195 (because ?\303 == 195)
(char-to-string 195) => "$(D**(B" (because 195==0xC3 U+00C3=='$(D**(B')
(string-match "$(D**(B" "$(D+#(B") => nil (obvious)

Any Lisp program that depends on the result of
string-as-unibyte (thus Emacs' internal character
representation) won't work in Emacs 23.

---
Kenichi Handa
handa <at> ni.aist.go.jp




This bug report was last modified 17 years and 45 days ago.

Previous Next


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