Re: [pcre-dev] Remove some restrictions of lookbehind assertions
On 2019-07-29 10:45, Zoltán Herczeg wrote: I am open to other names, but I would propose the following control verbs: (*MOVE:mark_name) - This verb changes the current string position to the position recorded by the last mark which name is mark_name. (*SETEND:mark_name) - This verb changes the end position to the position recorded by the last mark which name is mark_name. If the position is smaller than the current string position, it is set to the current string position. With these two opcodes you can move back in the string and you can even match parts of it again in a quite flexible way. I think MOVE verb like a goto operator in programming languages impacts the clarity of pattern structure and make it error-prone. It is undesirable in my opinion. It seems that very specific SETEND verb needed only in matching pattern in another pattern. But with this verb user must think not in terms of pattern structure but also with GOTO-like terms. I think it will be better to use standard "(?<=)" for lookbehinds, not MOVE+SETEND. MOVE and SETEND can exist in somehow internal PCRE level, not at userlevel I think. For example (?=X) internally may be syntactic sugar for (?>(*:M1)X(*MOVE:M1)) (?<=X) - for (?>(*:M1)(*:MOVE)(*SETEND:M1)(?:X)\z(*SETEND)) -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 2420] incorrect return type documented for pcre2_maketables
https://bugs.exim.org/show_bug.cgi?id=2420 Carlo Marcelo Arenas Belón changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.-- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 2420] incorrect return type documented for pcre2_maketables
https://bugs.exim.org/show_bug.cgi?id=2420 --- Comment #3 from Carlo Marcelo Arenas Belón --- Created attachment 1210 --> https://bugs.exim.org/attachment.cgi?id=1210=edit additional patch pcre2.h.generic likely to be fixed through the Release procedure (as I am hoping pcre2.txt) but the change in pcre2api.3 likely needs to be done regardless; apologize for missing it originally (somehow assumed was generated text) -- You are receiving this mail because: You are on the CC list for the bug.-- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 2426] New: PCRE: when extra->study_data==NULL, no need to write it (pcretest.c)
https://bugs.exim.org/show_bug.cgi?id=2426 Bug ID: 2426 Summary: PCRE: when extra->study_data==NULL, no need to write it (pcretest.c) Product: PCRE Version: 8.43 Hardware: x86 OS: All Status: NEW Severity: bug Priority: medium Component: Code Assignee: p...@hermes.cam.ac.uk Reporter: yangcon...@huawei.com CC: pcre-dev@exim.org Created attachment 1209 --> https://bugs.exim.org/attachment.cgi?id=1209=edit Patch for pcretest.c add a condtion 'extra->study_data==NULL' Good day! I think it's no need to write it when no study_data ,so I have added a condition 'extra->study_data==NULL'.Take a look please@Philip Hazel -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] Remove some restrictions of lookbehind assertions
On Wed, 31 Jul 2019, Zoltán Herczeg wrote: > If we consider the following pattern: > /(*napla:a|a)+/ > > is the same as: > /(?:(*napla:a|a))+/ > > Then we have an empty match if I understand correctly the behavior of > this new construct. Oh, sorry, I was thinking of (*MARK:X)(?:abc(*MOVE:X))+ which is not an empty match. Your example is indeed an empty match. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] Remove some restrictions of lookbehind assertions
> > You are right. Since you can put it into a group, it is not possible > > to prevent repetitions. However the rule that empty matches break > > (non-fixed) loops may solve this problem. > ... but it's not an empty match. If we consider the following pattern: /(*napla:a|a)+/ is the same as: /(?:(*napla:a|a))+/ Then we have an empty match if I understand correctly the behavior of this new construct. Regards, Zoltan -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] Remove some restrictions of lookbehind assertions
On Wed, 31 Jul 2019, Zoltán Herczeg wrote: > You are right. Since you can put it into a group, it is not possible > to prevent repetitions. However the rule that empty matches break > (non-fixed) loops may solve this problem. ... but it's not an empty match. > I start to understand why perl choose to implement assertions as atomic. Indeed. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] Remove some restrictions of lookbehind assertions
> as normal groups, not as assertion groups. What happens when they are > repeated must be defined - or maybe they should not be allowed to > repeat, because once again that might be an easy way to infinite loops. You are right. Since you can put it into a group, it is not possible to prevent repetitions. However the rule that empty matches break (non-fixed) loops may solve this problem. I start to understand why perl choose to implement assertions as atomic. Regards, Zoltan -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
