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. I hope this helps. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
