Good day!
Here is two pcretest.exe listings:
PCRE version 8.34-RC 2013-06-14
/(?(1)|2|.)*?(3|4)/
\Mabcdefghijklmnopqrstuvwxyz
Minimum match() limit = 217
Minimum match() recursion limit = 55
No match
PCRE version 8.34-RC 2013-06-14
/(?:(1)|2|.)*?(3|4)/
\Mabcdefghijklmnopqrstuvwxyz
Minimum
--- You are receiving this mail because: ---
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1419
--- Comment #21 from Philip Hazel p...@hermes.cam.ac.uk 2013-12-22 13:10:21
---
On Sun, 22 Dec 2013, Zoltan Herczeg wrote:
Philip, any comments for the patch?
Philip wrote
Go ahead, but perhaps edit the PCRE version to 8.35-RC1. We haven't
heard any immediate shouts for bugs in 8.34 (and we know people are
using it) so I guess it's OK to move forwards.
Zoltan wrote
Thanks! I also have several followup patches, since this new approach created
new
--- You are receiving this mail because: ---
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1423
Summary: Bad condition when optimizing character range checks
Product: PCRE
Version: N/A
Platform: Other
--- You are receiving this mail because: ---
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1423
Giuseppe D'Angelo dange...@gmail.com changed:
What|Removed |Added
Hi,
yes it seems there is a rubbish after the 'b'. However, I don't see this
behavior in the recent release (under Linux at least), and your binary is half
year old. Could you try it with a newer version?
Anyway I suspect the result is correct (it start with b), just the printing
does not
Hi Naden,
I like that you always have some interesting questions :) It is great to talk
about the internals and optimizations of PCRE.
Here is the answer to your question: in the second case, you see the effect of
an optimization called tail recursion. You can even see that in the first
case,
