From: Mikael Magnusson <mikachu@gmail.com>
To: Peter Stephenson <p.w.stephenson@ntlworld.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: PATCH: pattern incremental search
Date: Mon, 20 Dec 2021 04:40:32 +0100 [thread overview]
Message-ID: <CAHYJk3TkPP3=Gmc7Tv5ted3ey7KY37yu0DSaCL4=1qqOgr0TpA@mail.gmail.com> (raw)
In-Reply-To: <CAHYJk3Q5x=5Zn5kURXDDgLLoSEsro45_G=SZB-P+qX_qk7dn-Q@mail.gmail.com>
[forgot to change the ml address from sunsite.dk]
On 12/20/21, Mikael Magnusson <mikachu@gmail.com> wrote:
> On 4/26/08, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>> I think this is now good enough for some beta testing, though I'm sure
>> there must be glitches. It adds
>> history-incremental-pattern-search-backward and
>> history-incremental-pattern-search-forkward which are ridiculously long
>> names but nothing shorter really fits in with the names we have already.
>>
>> The limitation that only non-overlapping pattern matches on the same
>> line are found comes from the parameter substitution code I hijacked to
>> do this. It's not needed in this case since there's no substitution.
>> If anyone can see a good reason I can alter it.
>>
>> I've also finished the work of the previous patch that put history
>> searching back to using unmetafied strings: it was no longer necessary
>> to allocate additional space for each history line at all (unless it was
>> modified), so now it doesn't. This should be a significant saving for
>> searching large histories.
>>
>> Index: Src/glob.c
>> ===================================================================
>> RCS file: /cvsroot/zsh/zsh/Src/glob.c,v
>> retrieving revision 1.61
>> diff -u -r1.61 glob.c
>> --- Src/glob.c 1 Nov 2007 17:57:57 -0000 1.61
>> +++ Src/glob.c 26 Apr 2008 19:40:43 -0000
>> @@ -2050,12 +2050,6 @@
>> /* do the ${foo%%bar}, ${foo#bar} stuff */
>> /* please do not laugh at this code. */
>>
>> -struct repldata {
>> - int b, e; /* beginning and end of chunk to replace */
>> - char *replstr; /* replacement string to use */
>> -};
>> -typedef struct repldata *Repldata;
>> -
>> /* Having found a match in getmatch, decide what part of string
>> * to return. The matched part starts b characters into string s
>> * and finishes e characters in: 0 <= b <= e <= strlen(s)
>> @@ -2073,19 +2067,23 @@
>> char buf[80], *r, *p, *rr;
>> int ll = 0, l = strlen(s), bl = 0, t = 0, i;
>>
>> - if (replstr) {
>> + if (replstr || (fl & SUB_LIST)) {
>> if (fl & SUB_DOSUBST) {
>> replstr = dupstring(replstr);
>> singsub(&replstr);
>> untokenize(replstr);
>> }
>> - if ((fl & SUB_GLOBAL) && repllist) {
>> + if ((fl & (SUB_GLOBAL|SUB_LIST)) && repllist) {
>> /* We are replacing the chunk, just add this to the list */
>> - Repldata rd = (Repldata) zhalloc(sizeof(*rd));
>> + Repldata rd = (Repldata)
>> + ((fl & SUB_LIST) ? zalloc(sizeof(*rd)) : zhalloc(sizeof(*rd)));
>> rd->b = b;
>> rd->e = e;
>> rd->replstr = replstr;
>> - addlinknode(repllist, rd);
>> + if (fl & SUB_LIST)
>> + zaddlinknode(repllist, rd);
>> + else
>> + addlinknode(repllist, rd);
>> return s;
>> }
>> ll += strlen(replstr);
>
> Someone in the irc channel reported a crash on this strlen when doing
> history-incremental-pattern-search-backward with any search, and they
> can reproduce it with the latest git version too, they posted this
> backtrace:
>
> Program received signal SIGSEGV, Segmentation fault.
> __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
> 65 VPCMPEQ (%rdi), %ymm0, %ymm1
> (gdb) back
> #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
> #1 0x0000000000436eaa in get_match_ret (imd=imd@entry=0x7fffffffd460,
> b=<optimized out>, e=0) at glob.c:2571
> #2 0x000000000043742f in igetmatch (sp=sp@entry=0x7fffffffd4d8,
> p=<optimized out>, fl=fl@entry=8710, n=<optimized out>, n@entry=0,
> replstr=replstr@entry=0x0, repllistp=<optimized out>) at glob.c:3309
> #3 0x000000000043d7b0 in getmatchlist (str=<optimized out>,
> p=<optimized out>, repllistp=<optimized out>) at glob.c:2743
> #4 0x00007ffff774d4f6 in ?? () from /usr/lib64/zsh/5.8.0.2-dev/zsh/zle.so
> #5 0x0000000000000001 in ?? ()
> #6 0x0000000000000000 in ?? ()
>
> I'm not very familiar with this code, but it looks like this patch
> allows going into this path with a NULL replstr on purpose, but it
> also looks like it shouldn't work... I never had any issues with it
> before though, and I do use pattern search on ^R.
>
> --
> Mikael Magnusson
next prev parent reply other threads:[~2021-12-20 3:41 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 [this message]
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
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='CAHYJk3TkPP3=Gmc7Tv5ted3ey7KY37yu0DSaCL4=1qqOgr0TpA@mail.gmail.com' \
--to=mikachu@gmail.com \
--cc=p.w.stephenson@ntlworld.com \
--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).