Hi Philip,
many thanks again for your detailed helps,
On Sat, Jan 26, 2019 at 07:47:22PM +0000, ph10@??? wrote:
> On Sat, 26 Jan 2019, Ervin Hegedüs via Pcre-dev wrote:
>
> > well, now I'm a littlebit confused: the PCRE1 (8.xx) libraries
> > called libpcre3, and the PCRE2 (10.xx) libraries called
> > libpcre2...?
>
> I don't know what Debian do, but the standard names for the 8-bit
> libraries are libpcre for PCRE1 and libpcre2-8 for PCRE2. The 16-bit
> and 32-bit libraries have different names. I don't know where libpcre3
> comes from. On my Arch Linux box I have, for example,
>
> /usr/lib/libpcre.so* )
> /usr/lib/libpcre.so.1* ) PCRE1 8-bit library
> /usr/lib/libpcre.so.1.2.10* )
>
> /usr/lib/libpcre2-8.so* )
> /usr/lib/libpcre2-8.so.0* ) PCRE2 8-bit library
> /usr/lib/libpcre2-8.so.0.7.1* )
thanks - I'll try to cross this problem... :)
> > I'll try it with 10.32 - but if I understand correctly, this
> > "bug" will comes again, and the next release will be helped.
>
> The "bug" is not present in PCRE2. (At least, the tests I ran behaved
> differently and apparently correctly.)
yes, I thought PRCE1 - sorry,
> > ok, so what do you think? Should we align the library to new API?
> > https://www.pcre.org/current/doc/html/
> >
> > from this:
> > https://www.pcre.org/original/doc/html/
> >
> > and our problem solved?
>
> Well, yes, but it will be some work to adjust to the new API,
yes, of course,
> especially
> if you want to set up an ovector that adjusts its size to the pattern
> that is being processed. However, if you can do that it will be a good
> thing in the long run because PCRE1 is a dead-end.
I don't want to adjust ovector - if it doesn't necessary. Based
on this topic, I imagine that it not necessary.
> > Is there any other way that we keep the current one? Eg. as Zoli
> > said icrease the size of OVECTOR? If it is a solution, how should
> > we increase the size?
>
> That is certainly the quick short-term solution. The current value of 30
> allows for up to 10 capturing parentheses. So increase it to 300 and
> then you can have up to 100.
thanks! This was very useful.
May be we can create a new variable which could be read from the
config, and sysadmin can adjust this size...
> Actually, you can do better if you want to
> spend time and effort on PCRE1. There is a function called
> pcre_fullinfo() which enables you to find out how many capturing
> parentheses there are in a pattern. If there are more than 1/3 the size
> of OVECTOR you could do something... Personally, I think your time would
> be better spent converting to PCRE2, but it's your call.
yes - but this decision will generate so much things, eg. the
(package) contributors need to modify the build environments
(replace the PCRE1 - as it knows - to PCRE2).
(Note, that there is a 3rd solution, we ignore the
PCRE_STUDY_JIT_COMPILE flag, and uses pcre_study() without that...)
Thanks again, Philip
a.
