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* )
> 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.)
> 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, 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.
> 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. 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.
Philip
--
Philip Hazel
