https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #11 from firas ---
I'm glad we're on the same page now :-D
I don't see the purpose of allowing \K in assertions, but then again, I'm not
the most experienced regex user, so there might be useful scenarios.
I like your suggestion, and will
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #10 from Philip Hazel ---
OH SILLY ME. I should have looked more closely at the code in pcre2demo. It has
special code to deal with this case. Here is the comment:
/* If the previous match was not an empty string, there is one tricky case
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #9 from firas ---
The implementation on regex101 is returning a match with start index 21 and end
index 22, which then means it tries to find another match on index 22. It finds
another one, again, at index 21-22, and keeps repeating this
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #8 from Philip Hazel ---
I wonder how PHP is programming it to make it loop? If you ask pcre2_match() to
match that pattern against that string, the result comes back with a match at
offset 21, with the end of the match at 22 - which is the
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #7 from firas ---
Yes, they look correct.
I have been unable to reproduce the issue with the implementation of pcre2test
and similar. However, PHP, which runs a widely used implementation of PCRE, has
this issue (in both PCRE1 and PCRE2).
https://bugs.exim.org/show_bug.cgi?id=2792
Zoltan Herczeg changed:
What|Removed |Added
CC||hzmes...@freemail.hu
--- Comment #5 from
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #4 from firas ---
If you check the links I provided, both implementations (that of regex101 and
multiple versions of PHP), they both result in infinite loops.
I haven't checked how pcre2test breaks out of it, but clearly there is a
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #3 from Philip Hazel ---
Hmm. Have I missed something? I tried the pattern you quoted and didn't get an
infinite loop (this is pcre2test):
PCRE2 version 10.37 2021-05-26
/(?<=(<|>|=)\K=)/
50||(7<=Dex&&8>=MHP)==2
0: =
1: <
Which is what I
We had had a similar discussion a few years back, where I stated that a certain
usage is wrong and you answered that changing PCRE will break a few patterns
who may rely on the wrong usage. In the end you've adopted my view after I'd
asked to allow me an exception in the z/OS EBCDIC specific
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #2 from firas ---
Thanks for the reply.
I stumbled upon this due to the following regex by a user:
https://regex101.com/r/7PPxPD/1/
This results in an infinite loop, even in other implementations such as PHP:
https://3v4l.org/F4NhG
It
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #1 from Philip Hazel ---
Perl used to allow \K in lookarounds. I am aware that it has changed, and this
is documented in pcre2pattern:
"Perl used to document that the use of \K within lookaround assertions is "not
well defined", but from
11 matches
Mail list logo
