著者: Ervin Hegedüs 日付: To: Zoltán Herczeg CC: pcre-dev@exim.org 題目: Re: [pcre-dev] PCRE_STUDY_JIT_COMPILE option bug?
Hi Zoli,
many thanks for your reply,
On Sat, Jan 26, 2019 at 02:18:33PM +0100, Zoltán Herczeg wrote: > Hi Ervin,
>
> 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.
I don't know inside of PCRE, and the used API (I just fond a
"bug" on of my project), so I think I have to see, what does it
mean the ovector. The application can use longest pattern, than
this... so I guess the 40 isn't the solution for "all cases".
Is there any best practice to calculate the size? What other
consequence is there, when I increase that size? Eg. more memory
using, slower runtime...?
> 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.
The "for some reason" is a little bit disquieting :), you mean
that this result is not deterministic?