From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" Date: Wed, 19 Oct 2016 10:02:38 +0300 Message-ID: <83zim0vn1t.fsf@gnu.org> References: <87twe6sx2g.fsf@users.sourceforge.net> <87eg51ng4r.fsf_-_@users.sourceforge.net> <87k2djwumn.fsf@users.sourceforge.net> <83h98nidvd.fsf@gnu.org> <87eg3rvtsf.fsf@users.sourceforge.net> <83k2dihpm9.fsf@gnu.org> <8760p2wzgj.fsf@users.sourceforge.net> <838ttyhhzu.fsf@gnu.org> <871szqwu51.fsf@users.sourceforge.net> <831szqhbc2.fsf@gnu.org> <87h98hujcx.fsf@users.sourceforge.net> <831szkahyz.fsf@gnu.org> <87eg3jvfj6.fsf@users.sourceforge.net> <8360ov8lbu.fsf@gnu.org> <877f95uj66.fsf@users.sourceforge.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476860674 8554 195.159.176.226 (19 Oct 2016 07:04:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 07:04:34 +0000 (UTC) Cc: sam.halliday@gmail.com, 24358@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 19 09:04:30 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwkv7-0007zv-HP for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Oct 2016 09:04:13 +0200 Original-Received: from localhost ([::1]:45966 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwkv9-0006b9-M4 for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Oct 2016 03:04:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwkuz-0006ZN-M9 for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2016 03:04:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwkuw-0001bn-Gp for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2016 03:04:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60744) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bwkuw-0001bY-Dz for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2016 03:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bwkuv-000220-Tc for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2016 03:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Oct 2016 07:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24358 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 24358-submit@debbugs.gnu.org id=B24358.14768605897740 (code B ref 24358); Wed, 19 Oct 2016 07:04:01 +0000 Original-Received: (at 24358) by debbugs.gnu.org; 19 Oct 2016 07:03:09 +0000 Original-Received: from localhost ([127.0.0.1]:38701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwku4-00020l-Rx for submit@debbugs.gnu.org; Wed, 19 Oct 2016 03:03:09 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59663) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwku2-00020F-OZ for 24358@debbugs.gnu.org; Wed, 19 Oct 2016 03:03:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwktw-00016j-4s for 24358@debbugs.gnu.org; Wed, 19 Oct 2016 03:03:01 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwktr-00015L-PH; Wed, 19 Oct 2016 03:02:55 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2641 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwktq-0006M6-M7; Wed, 19 Oct 2016 03:02:55 -0400 In-reply-to: <877f95uj66.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:124668 Archived-At: > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, Sam Halliday > Date: Tue, 18 Oct 2016 23:11:45 -0400 > > > Then yes, you will need to somehow pass down the object from which the > > text comes. It can be in some global variable, for instance, if > > changing the function's signature is undesirable. > > I decided that a global variable would be a bad idea since it would > still effectively be part of the calling convention, and too easy for > callers to forget. That's true, but doing this is a standard Emacs coding practice, used in quite a few other places. > But just after finishing the patch I noticed this: > > /* In Emacs, this is the string or buffer in which we > are matching. It is used for looking up syntax properties. */ > Lisp_Object re_match_object; Indeed. > So now I'm thinking it might be better to reuse that variable instead. > Although it only seems to get to Qt, Qnil, and string objects; I'm not > sure what the meaning of Qt and Qnil are. nil means current buffer, t means a C string. (This is standard Emacs convention, used in other places as well, but you can verify it is used in this case by looking at all the places where these values are assigned.) The last case, of a C string, doesn't need to bother about relocation, of course (but you could ignore that distinction for simplicity of the code, if you want, it will never do any harm). I guess you will be rewriting your patch to use re_match_object? I expect it to be much simpler and smaller. re_match_object is already staticpro'd, btw, so you don't need to worry about GC for the Lisp object (a string) that gets put in its value. However, I think we should assign Qnil to re_match_object as soon as re_match_2 returns, to avoid having the string protected from GC for too long. A couple of comments to the patch: > +#ifdef emacs > +#define STR_BASE_PTR(obj) \ > + (BUFFERP (obj)? XBUFFER (obj)->text->beg : \ > + STRINGP (obj)? SDATA (obj) : \ > + NULL) There's an unnecessary complication here: since, when regex functions are invoked to search a buffer, that buffer is always the current buffer, you don't need to pass the buffer object and use XBUFFER, because the current buffer is always available in the global variable current_buffer (which is a C struct, not a Lisp object). So you could adopt the usual semantics of passing Qnil to mean the current buffer and a string object to mean that string. Then the only test in the macro should be STRINGP. > #define ENSURE_FAIL_STACK(space) \ > while (REMAINING_AVAIL_SLOTS <= space) { \ > + re_char* orig_base = STR_BASE_PTR (string_base); \ > if (!GROW_FAIL_STACK (fail_stack)) \ > - return -2; \ > + return -2; \ > + /* GROW_FAIL_STACK may call malloc and relocate the string */ \ > + /* pointers. */ \ > + ptrdiff_t delta = STR_BASE_PTR (string_base) - orig_base; \ > + if (string1) \ > + { \ > + string1 += delta; \ > + end1 += delta; \ > + end_match_1 += delta; \ > + } \ > + if (string2) \ > + { \ > + string2 += delta; \ > + end2 += delta; \ > + end_match_2 += delta; \ > + } \ > + d += delta; \ > + dend += delta; \ > + dfail += delta; \ I think doing this via buffer and string positions instead would yield slightly more portable code, since Standard C says subtraction of pointers to different objects yields undefined behavior. Thanks.