bug#65726: 29.1.50; Crash in regexp engine

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

18 sep. 2023 kl. 14.32 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

> In the mean time the patch below recognizes the above pattern, which
> gives me code which is safe (it should both always terminate and should
> never apply the optimization if it's not valid) yet does find the
> optimization in all the cases where I expected it.

Yes, maybe this would work but the ad-hocness of it all means that I very much could have missed something (and as you comment, that it's brittle).

> 	case succeed_n:
> -	  /* If N == 0, it should be an on_failure_jump_loop instead.  */
> -	  DEBUG_STATEMENT (EXTRACT_NUMBER (j, p + 2); eassert (j > 0));
> +	  /* If N == 0, it should be an on_failure_jump_loop instead.
> +	     `j` can be negative because `EXTRACT_NUMBER` extracts a
> +	     signed number whereas `succeed_n` treats it as unsigned.  */
> +	  DEBUG_STATEMENT (EXTRACT_NUMBER (j, p + 2); eassert (j != 0));

So this is what prevented me from running with counts above 2**15 and debugging enabled for all these years...

> +  if (loop_exit && p2 > loop_exit)
> +    {
> +      void print_compiled_pattern (struct re_pattern_buffer *bufp);
> +      print_compiled_pattern (bufp);
> +      fprintf (stderr, "p1==%d, p2==%d, loop-entry==%d, loop-exit==%d\n",
> +               p1 - bufp->buffer, p2 - bufp->buffer,
> +               loop_entry - bufp->buffer, loop_exit - bufp->buffer);
> +      error ("WOW1!");

#ifdef REGEX_EMACS_DEBUG ?

> +    }
> +    /* return false; */