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

[Eli Zaretskii]

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