/* patmatchlen returns metafied length, as we need */
                On Thu, Mar 31, 2022 at 8:49 PM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> The following appears to fix the crash problem.  I don't know what
> else the rest of the patch in workers/49781 accomplishes.

Hmm, sorry ... that fixes the crash when there is no match on the
search, but there is still a crash when the search does begin to match
something.

I note this commentary difference from the MULTIBYTE to not-so case,
which I hope is correct:

-                /* patmatchlen returns unmetafied length in this case */
+                /* patmatchlen returns metafied length, as we need */

Also in the MULTIBYTE branch, we have declared two "char *mpos" in
nested scopes, and I can't immediately tell whether that's a bug
waiting to be surfaced or if the not-MULTIBYTE branch just needs to
declare the outer mpos.  This has a potential effect because there's a
call to get_match_ret(&imd, t-s, mpos-s); that is in the outer (loop)
scope in the MULTIBYTE branch but the inner ("if (pattrylen(...))")
scope in the not-MULTIBYTE branch.  I would expect one of those
placements must be wrong?

Those differences aside, the hunk from workers/49781 that prevents the
crash in the successful-match case is this one:

@@ -3481,6 +3481,7 @@ igetmatch(char **sp, Patprog p, int fl, int n,
char *replstr,
      * Results from get_match_ret in repllist are all metafied.
      */
     s = *sp;
+    if (!(fl & SUB_LIST)) {
     i = 0;            /* start of last chunk we got from *sp */
     for (nd = firstnode(imd.repllist); nd; incnode(nd)) {
         rd = (Repldata) getdata(nd);

(plus the matching close-brace, of course).  SUB_LIST is explained as
/* no substitution, return list of matches */
so I'm somewhat concerned that there remains a different way to enter
this code that is still going to crash it, but I don't know how to
force that path.

Anyway, a shorter but equivalent (requires no re-indentation) fix is
included in the patch below.  I have not attempted to resolve the
"mpos" question.  I did pull in a couple of what appear to be
optimizations (early loop break) from the MULTIBYTE code.