Re: [pcre-dev] (*SKIP:NAME) when (*MARK:NAME) is in assertion
On 2018-07-14 15:12, ph10 wrote: Feel free to look at the code and suggest patches. However, I don'tthink is is easy. Sorry. I'm not ะก programmer. It doesn't have to do anything special when it passes a (*MARK:NAME) other than record a backtracking point. Then when (*SKIP:NAME) is triggered, it backtracks till it hits a matching (*MARK:NAME) and then the current position in the subject is where to bumpalong to. I wonder that engine not doing something special. Consider this example: PCRE2 version 10.31 2018-02-12 /(*NO_START_OPT)\A(?>(*:1)a)((*:2)x|)/mark ab 0: a 1: MK: 1 Resulting mark is "1" when no backtracking is allowed to it. So I can guess PCRE do a special: it copies a pointers to mark names to another memory places. May be it copies pointer to current mark in every backtracking frame. May be something else *special* tactic. Isn't it? Keeping a separate table would require memory management, and its own backtracking mechanism! If a branch that contains a (*MARK:NAME) fails to match, the (*MARK) must be forgotten. Consider /(xxx(*MARK:A)xxx|yyy(*MARK:A)yyy)...(*SKIP:A).../ Now I don't see any extended backtracking needs. Only unsetting of "Mark-Position" fields of table. Howbeit I see that such changes can be made in theory only after Perl changed accordingly. I can't neither report to Perl authors about this weird and unobvious behavior, nor programming in C. So you free to close this topic. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] (*SKIP:NAME) when (*MARK:NAME) is in assertion
On Sat, 14 Jul 2018, ND via Pcre-dev wrote: > It seems instead of maintaining only MarkNames PCRE can maintain a table with > MarkName-MarkPosition pares. And so not have need to backtrack to access MARK > position data. And not loose MarkPosition information. Feel free to look at the code and suggest patches. However, I don't think is is easy. At present, the matching engine does everything by backtracking. Note that this gives the same results as Perl. It doesn't have to do anything special when it passes a (*MARK:NAME) other than record a backtracking point. Then when (*SKIP:NAME) is triggered, it backtracks till it hits a matching (*MARK:NAME) and then the current position in the subject is where to bumpalong to. Keeping a separate table would require memory management, and its own backtracking mechanism! If a branch that contains a (*MARK:NAME) fails to match, the (*MARK) must be forgotten. Consider /(xxx(*MARK:A)xxx|yyy(*MARK:A)yyy)...(*SKIP:A).../ The *SKIP must activate whichever MARK matched, because they may have different bumpalong points. I think what you are suggesting would be very difficult to implement. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] (*SKIP:NAME) when (*MARK:NAME) is in assertion
On 2018-07-14 07:16, ph10 wrote: >> Why it need to backtrack? > Why not do a "bumpalong" advance to the next starting character strait away? It has to backtrack to the *MARK because that is where the bumpalongdata is remembered. There may be many *MARKs, each with a differentname. You can't just keep a single data item. I think this is something weird here: PCRE during matching process have information about all passed MARK names and MARK positions. Information about MARK names is somewhere nearby and can be easily retrieved. Information about MARK positions is saved somewhere deep and can be retrieved only by backtracking. If no backtracking available then there is no way to access information. It seems instead of maintaining only MarkNames PCRE can maintain a table with MarkName-MarkPosition pares. And so not have need to backtrack to access MARK position data. And not loose MarkPosition information. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] (*SKIP:NAME) when (*MARK:NAME) is in assertion
On Sat, 14 Jul 2018, ND via Pcre-dev wrote: > On 2018-07-13 16:08, ph10 wrote: > >When SKIP has a name, it backtracks until it hits a MARK with the samename. > > > > Why it need to backtrack? > Why not do a "bumpalong" advance to the next starting character strait away? It has to backtrack to the *MARK because that is where the bumpalong data is remembered. There may be many *MARKs, each with a different name. You can't just keep a single data item. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
