On Sat, 26 Jan 2019, Zoltán Herczeg wrote:
> The result value is misinterpreted by showresult ().
> PCRE_ERROR_NOMATCH is -1, not 0. The 0 value represents that a match
> is found, but the ovector is too small to store all capturing bracket
> positions. So increasing #define OVCOUNT from 30 to 40 "solves" the
> JIT case. For some reason the interpreter returns the highest
> capturing bracket below the end of ovector, which is kind of
> misleading, since there are valid capturing positions outside of that
> region. Philip, is this intended?
Thanks for checking this out, Zoltán. I've just reproduced the test in
pcretest. It looks like a small bug in PCRE1. Running the same test on
PCRE2 with pcre2test gives identical results both with and without JIT.
So it looks like the issue has been fixed at some stage, though I can't
find a ChangeLog entry that specifically mentions it. It may have
happened during the big PCRE1->PCRE2 conversion.
Ervin,
Current development of PCRE is called PCRE2 (the 10.xx series of
releases). I recommend that you upgrade to using a recent release if at
all possible. I realize this is non-trivial, because the API has changed
(that was the whole point of creating PCRE2).
PCRE1 (the 8.xx series) is obsolescent and the only forseen changes are
major bugfixes, and I'm not expecting many (any?) of these now. The
latest release (8.42) has been out a year, and the next one (8.43) has
just been released as a Release Candidate. Only 9 changes happened
during that year, and my hope is that we are nearing the final release.
It has been four years since PCRE2 was released and I've forgotten a lot
about how it works. I had to read the manual to remember how to set up
the pcretest input, and I know that if I have to look at the code it
will be almost like starting with a strange program. I do not think this
is a sufficiently serious issue to spend time trying to find out why the
output differs.
