zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Madhu <enometh@meer.net>
Cc: "Lawrence Velázquez" <larryv@zsh.org>,
	"Zsh hackers list" <zsh-workers@zsh.org>
Subject: Re: PATCH: pattern incremental search
Date: Fri, 1 Apr 2022 11:23:41 -0700	[thread overview]
Message-ID: <CAH+w=7Ya4cJqDcTpYrAz-PdMM_=TzeYYAYKF+9anNY+sJAnYJw@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7bHbuX=LwrcVok35veVY9uqhD9uW2A4NXrJQ5cWWA1+CQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

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

[-- Attachment #2: glob-pattern-search.txt --]
[-- Type: text/plain, Size: 2399 bytes --]

diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index d9d9503e2..c8c6f78c6 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -255,7 +255,9 @@ int cost;
 #endif
 
 static const REFRESH_ELEMENT zr_cr = { ZWC('\r'), 0 };
+#ifdef MULTIBYTE_support
 static const REFRESH_ELEMENT zr_dt = { ZWC('.'), 0 };
+#endif
 static const REFRESH_ELEMENT zr_nl = { ZWC('\n'), 0 };
 static const REFRESH_ELEMENT zr_sp = { ZWC(' '), 0 };
 static const REFRESH_ELEMENT zr_zr = { ZWC('\0'), 0 };
diff --git a/Src/glob.c b/Src/glob.c
index 349862531..d4ffc2274 100644
--- a/Src/glob.c
+++ b/Src/glob.c
@@ -3286,6 +3286,7 @@ igetmatch(char **sp, Patprog p, int fl, int n, char *replstr,
 	return 1;
     }
     if (matched) {
+        /* Default is to match at the start; see comment in MULTIBYTE above */
 	switch (fl & (SUB_END|SUB_LONG|SUB_SUBSTR)) {
 	case 0:
 	case SUB_LONG:
@@ -3355,7 +3356,7 @@ igetmatch(char **sp, Patprog p, int fl, int n, char *replstr,
 	    /* longest or smallest at start with substrings */
 	    t = s;
 	    if (fl & SUB_GLOBAL) {
-		imd.repllist = newlinklist();
+		imd.repllist = (fl & SUB_LIST) ? znewlinklist() : newlinklist();
 		if (repllistp)
 		    *repllistp = imd.repllist;
 	    }
@@ -3405,6 +3406,8 @@ igetmatch(char **sp, Patprog p, int fl, int n, char *replstr,
 			 * which is already marked for replacement.
 			 */
 			matched = 1;
+			if (t == send)
+			    break;
 			while (t < mpos) {
 			    ioff++;
 			    umlen--;
@@ -3412,8 +3415,10 @@ igetmatch(char **sp, Patprog p, int fl, int n, char *replstr,
 			}
 			break;
 		    }
+		    if (t == send)
+			break;
 		}
-	    } while (matched);
+	    } while (matched && t < send);
 	    /*
 	     * check if we can match a blank string, if so do it
 	     * at the start.  Goodness knows if this is a good idea
@@ -3485,6 +3490,8 @@ 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)
+	    return 1;
 	i = 0;			/* start of last chunk we got from *sp */
 	for (nd = firstnode(imd.repllist); nd; incnode(nd)) {
 	    rd = (Repldata) getdata(nd);
@@ -3514,7 +3521,7 @@ igetmatch(char **sp, Patprog p, int fl, int n, char *replstr,
     imd.replstr = NULL;
     imd.repllist = NULL;
     *sp = get_match_ret(&imd, 0, 0);
-    return 1;
+    return (fl & SUB_RETFAIL) ? 0 : 1;
 }
 
 /**/

      reply	other threads:[~2022-04-01 18:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-26 19:41 Peter Stephenson
2008-04-26 20:22 ` Peter Stephenson
2008-04-26 20:35   ` Peter Stephenson
2008-04-26 20:51     ` Peter Stephenson
2008-04-26 23:52 ` Bart Schaefer
2008-04-28  1:35 ` Geoff Wing
     [not found] ` <CAHYJk3Q5x=5Zn5kURXDDgLLoSEsro45_G=SZB-P+qX_qk7dn-Q@mail.gmail.com>
2021-12-20  3:40   ` Mikael Magnusson
2021-12-20 12:10     ` Peter Stephenson
2022-02-28 16:54       ` Madhu
2022-03-31 22:44         ` Lawrence Velázquez
2022-04-01  2:25           ` Madhu
2022-04-01  3:49             ` Bart Schaefer
2022-04-01 18:23               ` Bart Schaefer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7Ya4cJqDcTpYrAz-PdMM_=TzeYYAYKF+9anNY+sJAnYJw@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=enometh@meer.net \
    --cc=larryv@zsh.org \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).