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 17:37:28 +0300 Message-ID: <83insov1zr.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> <83zim0vn1t.fsf@gnu.org> <874m48v7wj.fsf@users.sourceforge.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476887908 17692 195.159.176.226 (19 Oct 2016 14:38:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 14:38:28 +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 16:38:24 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 1bws0P-0002Q3-NY for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Oct 2016 16:38:09 +0200 Original-Received: from localhost ([::1]:48974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bws0R-0007n9-V9 for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Oct 2016 10:38:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bws0I-0007lW-UY for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2016 10:38:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bws0H-0007ut-VK for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2016 10:38:02 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33711) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bws0H-0007uf-S0 for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2016 10:38:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bws0H-0008KP-MJ for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2016 10:38: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 14:38: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.147688787832004 (code B ref 24358); Wed, 19 Oct 2016 14:38:01 +0000 Original-Received: (at 24358) by debbugs.gnu.org; 19 Oct 2016 14:37:58 +0000 Original-Received: from localhost ([127.0.0.1]:39901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bws0E-0008K7-HS for submit@debbugs.gnu.org; Wed, 19 Oct 2016 10:37:58 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bws0D-0008Jv-0b for 24358@debbugs.gnu.org; Wed, 19 Oct 2016 10:37:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bws06-0007na-U3 for 24358@debbugs.gnu.org; Wed, 19 Oct 2016 10:37:51 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bws00-0007kl-KI; Wed, 19 Oct 2016 10:37:44 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3582 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwrzz-0005zm-QV; Wed, 19 Oct 2016 10:37:44 -0400 In-reply-to: <874m48v7wj.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:124678 Archived-At: > From: npostavs@users.sourceforge.net > Cc: 24358@debbugs.gnu.org, sam.halliday@gmail.com > Date: Wed, 19 Oct 2016 08:29:48 -0400 > > > 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.) > > It would be nice to have a comment in the code about this. Done. (Please update the comment when you are done with the change of using that variable for this additional purpose.) > I saw that it was set to nil in search_buffer etc, but that just > confused me since I took nil to mean "nothing". Yeah, it can be confusing when you first bump into it. > > 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. > > Do you mean staticpro prevents relocation (not just collection)? > In that case wouldn't it be even simpler to assign the buffer object to > re_match_object? No, it only makes sure the objects will not be GC'ed, it doesn't prevent relocation. Every staticpro'd variable is marked at the beginning of GC, which includes marking any Lisp object that is referenced, directly or indirectly, from the staticpro'd variable. Btw, note that regex.c already has macros PTR_TO_OFFSET and POS_AS_IN_BUFFER which you can use. Thanks.