Hi Philip, many thanks again for your detailed helps,
On Sat, Jan 26, 2019 at 07:47:22PM +0000, [email protected] 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. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
