Bug in PCRE

[jchd18]

A bug in recent releases of the PCRE library has been reported which may affect users running the 3.3.13.19 beta (the 3.3.12.0 release is OK):

In caseless utf modes, it is possible for character classes to be missing the lowercase version of some ascii characters.

Example below shows that the beta gives a wrong result (the range a-j is missed), yet the release behaves correctly:

ConsoleWrite(StringRegExpReplace("ABCDEFGHIJKLmonpqrstuvwxyz[\]^_` 123456 abcdefgijklmnopqrstuvwxyz", "(?i)([A-`])", "*") & @LF)

Advice: if you need the beta, make character ranges in classes more explicit, until Dev team can link a fixed version of PCRE in a new AutoIt beta or release.

Remark: no change in PCRE can be found in the changelog between release 3.3.12.0 and beta 3.3.13.19 but the code sample above clearly demonstrate they don't use the same PCRE version.

[J-Paul Mesnage]

In fact PCRE has been updated to 8.35 in 3.3.13.13
It can be related I will check

[J-Paul Mesnage]

After a test 8.35 induce the regression if it is really a regression

[jchd18]

Yes it is. It also crept in PCRE2 (10.00 and 10.10RC2 exhibit the same bug). No doubt it will be fixed soon by Philip Hazel & co.

[J-Paul Mesnage]

Is it reported to Phillip Hazel?
Any new if PCRE2 (10.20)?

[jchd18]

The bug was reported to the dev list and quickly fixed some time ago.
PCRE2 is moving forward. There is a RC being tested but I expect some time before the dust settles.

[jchd18]

I notice that the last release (3.3.14.0) dated 2015-07-10 uses PCRE v8.35 (dated 2014-04-04) instead of the last available version, 8.37 dated 2015-04-28. This explains why the bug in this "ticket" (rather a notice) can still show.

[J-Paul Mesnage]

I confirm 8.37 is solving the pb

[Jon]

Fixed by revision [11405] in version: 3.3.15.0