From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Discrepancy in definition/use of match-data? Date: Sat, 12 Jun 2004 15:45:51 +0900 Organization: The XEmacs Project Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87vfhx46lc.fsf@tleepslib.sk.tsukuba.ac.jp> References: <87n03a7as9.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1087022767 20242 80.91.224.253 (12 Jun 2004 06:46:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 12 Jun 2004 06:46:07 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Jun 12 08:45:59 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BZ2H8-00089B-00 for ; Sat, 12 Jun 2004 08:45:58 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BZ2H8-0002Gl-00 for ; Sat, 12 Jun 2004 08:45:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BZ2Hu-0006z5-P1 for emacs-devel@quimby.gnus.org; Sat, 12 Jun 2004 02:46:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BZ2Hs-0006z0-3S for emacs-devel@gnu.org; Sat, 12 Jun 2004 02:46:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BZ2Hr-0006yo-Fa for emacs-devel@gnu.org; Sat, 12 Jun 2004 02:46:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BZ2Hr-0006yl-DX for emacs-devel@gnu.org; Sat, 12 Jun 2004 02:46:43 -0400 Original-Received: from [130.158.98.109] (helo=tleepslib.sk.tsukuba.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BZ2H2-0003Sn-2s; Sat, 12 Jun 2004 02:45:52 -0400 Original-Received: from steve by tleepslib.sk.tsukuba.ac.jp with local (Exim 3.36 #1 (Debian)) id 1BZ2H1-0006Fo-00; Sat, 12 Jun 2004 15:45:51 +0900 Original-To: David Kastrup In-Reply-To: (David Kastrup's message of "11 Jun 2004 10:54:05 +0200") User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.5 (chayote, linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:24859 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24859 >>>>> "David" == David Kastrup writes: David> How strong were the results from the regression test? What does that mean? There is one test that specifically checks for match-data being preserved across a failed match, and it failed. David> What kind and amount of code appears to be affected? Kind? I know of one specific use in `w3-configuration-data' in w3-cfg.el which calls itself recursively, and depends on being able to use the top-level match-data if the match in the recursive call fails, while using the match-data from the recursive call otherwise. Too sneaky to live, I suppose you could say. Amount? How should I know? I can say I've tried inserting warning code in match_limit and file-name-sans-extension produces the warning during the dump phase. I don't know why yet, my implementation may be incorrect (the flag is either getting reset when it shouldn't, or fails to get set on a successful search---the Boyer-Moore code is the most complicated thing I've ever tried to deal with). However, I know that file-handlers can get called there, via file-name-directory inter alia. In general, even a simple variable reference can call arbitrary Lisp code in XEmacs (because of magic Mule handlers) and most likely GNU Emacs (because those handlers were introduced for GNU Emacs compatibility). David> With the current code. But I was also proposing to void David> the match-data in the main loop: that would produce errors David> more often, and only in situations where the match-data was David> completely unpredictable to start with (and possibly David> undefined, too). But that's not true. The match-data was sufficiently predictable that split-string only failed when it was voided. I think it's likely that that mistake has been made elsewhere. On the other hand, pretty much any time any Lisp code intervenes between the return of the matching function and entry to the match data access there is an opportunity for a hook or handler to be called. Probability of hitting it on any given path is low, but potential for random annoyance for years to come is high, I fear. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.