bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24358: 25.1.50; re-search-forward errors with "Variable binding dept


From: Eli Zaretskii
Subject: bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size"
Date: Thu, 20 Oct 2016 11:39:54 +0300

> From: npostavs@users.sourceforge.net
> Cc: 24358@debbugs.gnu.org,  sam.halliday@gmail.com
> Date: Thu, 20 Oct 2016 00:31:50 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> +#ifdef emacs
> >> +#define STR_BASE_PTR(obj)                       \
> >> +    (BUFFERP (obj)? XBUFFER (obj)->text->beg :  \
> >> +     STRINGP (obj)? SDATA (obj) :               \
> >> +     NULL)
> >
> 
> [...]
> 
> > the only test in the macro should be STRINGP.
> 
> Hmm, not sure I feel comfortable being that implicit.  I kept this macro
> the same except for using (NILP (obj)? current_buffer->...) instead of
> BUFFERP and XBUFFER.

Fine with me.

> Here is the new patch:

LGTM, a few minor comments below.

> +#ifdef emacs
> +#define STR_BASE_PTR(obj)                   \
> +  (NILP(obj)? current_buffer->text->beg :   \
          ^
Please leave a blank before the left parenthesis where indicated.
Also, another blank between the right parenthesis and the following
question mark.

> +   STRINGP (obj)? SDATA (obj) :             \

Likewise here.

> diff --git a/src/regex.h b/src/regex.h
> index 51f4424..d5c9690 100644
> --- a/src/regex.h
> +++ b/src/regex.h
> @@ -169,7 +169,8 @@ extern reg_syntax_t re_syntax_options;
>  #ifdef emacs
>  # include "lisp.h"
>  /* In Emacs, this is the string or buffer in which we are matching.
> -   It is used for looking up syntax properties.
> +   It is used for looking up syntax properties, and also to recompute
> +   pointers in case the object is relocated by GC.

Not "by GC", but "as a side effect of calling malloc".  Maybe it's a
good idea to also mention ralloc.c here.

> +  /* Get pointers and sizes of the two strings that make up the
> +     visible portion of the buffer.  Note that we can use pointers
> +     here, unlike in search_buffer, because we only call re_match_2
> +     once.  */

I'm not sure the reader will understand the significance of calling
re_match_2 only once.  It would be good to clarify the comment.

Otherwise, I think this should go in.

Thanks!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]