https://bugs.exim.org/show_bug.cgi?id=1679
Zoltan Herczeg hzmes...@freemail.hu changed:
What|Removed |Added
CC||hzmes...@freemail.hu
---
https://bugs.exim.org/show_bug.cgi?id=1679
--- Comment #3 from henrik.h...@aol.de ---
Would there arrive confusion about memory responsibility if just new strings
were allocated and be returned when a capture string is modified, or
unacceptable work to be done on a regular basis for a feature
On 2015-08-28 15:15, ph10 wrote:
What is the output of pcretest -C?
PCRE version 8.38-RC1 2015-05-03
Compiled with
8-bit support
UTF-8 support
16-bit support
UTF-16 support
32-bit support
UTF-32 support
Unicode properties support
Just-in-time compiler support: x86 32bit
On Thu, 27 Aug 2015, ND wrote:
On 2015-08-27 15:34, ph10 wrote:
Please post the pattern that causes this error.
Here is pcretest listing that have total 2015 forward references to named
subpattern a:
I am afraid I cannot reproduce the error. It works for me, and valgrind
shows no
https://bugs.exim.org/show_bug.cgi?id=1680
--- Comment #1 from Philip Hazel p...@hermes.cam.ac.uk ---
I don't think ^a\d+b$ is the intersection of ^a\d+ and \d+b$ if you mean
matches strings that match each separate pattern. I think the intersection is
^a\d+(.+\d+)?b$ because the first means
https://bugs.exim.org/show_bug.cgi?id=1679
--- Comment #4 from Philip Hazel p...@hermes.cam.ac.uk ---
Currently, pcre2_substitute() gives access only to captured substrings in the
replacement string. It would be possible to allow it to access the MARK string,
in which case you could do something
https://bugs.exim.org/show_bug.cgi?id=1679
--- Comment #5 from henrik.h...@aol.de ---
Philip Hazel:
The code for this should be straighforward and might be generally useful, so
I'll implement it and see how it feels.
That's great. Thanks!
As you can see from the Perl examples I provided, )
