bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size"

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: npostavs@users.sourceforge.net
>> Cc: 24358@debbugs.gnu.org, Sam Halliday <sam.halliday@gmail.com>
>> Date: Tue, 18 Oct 2016 23:11:45 -0400
>> 
>>     /* 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.)
>

It would be nice to have a comment in the code about this.  I saw that
it was set to nil in search_buffer etc, but that just confused me since I
took nil to mean "nothing".

>
> 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?