| 1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
| 2 |
------------------ |
------------------ |
| 3 |
|
|
| 4 |
Version 7.5 23-Dec-07 |
Version 7.6 19-Jan-08 |
| 5 |
|
--------------------- |
| 6 |
|
|
| 7 |
|
1. A character class containing a very large number of characters with |
| 8 |
|
codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer |
| 9 |
|
overflow. |
| 10 |
|
|
| 11 |
|
2. Patch to cut out the "long long" test in pcrecpp_unittest when |
| 12 |
|
HAVE_LONG_LONG is not defined. |
| 13 |
|
|
| 14 |
|
|
| 15 |
|
Version 7.5 10-Jan-08 |
| 16 |
--------------------- |
--------------------- |
| 17 |
|
|
| 18 |
1. Applied a patch from Craig: "This patch makes it possible to 'ignore' |
1. Applied a patch from Craig: "This patch makes it possible to 'ignore' |
| 110 |
|
|
| 111 |
20. In pcrecpp.cc, the variable 'count' was incremented twice in |
20. In pcrecpp.cc, the variable 'count' was incremented twice in |
| 112 |
RE::GlobalReplace(). As a result, the number of replacements returned was |
RE::GlobalReplace(). As a result, the number of replacements returned was |
| 113 |
double what it should be. I have removed one of the increments. |
double what it should be. I removed one of the increments, but Craig sent a |
| 114 |
|
later patch that removed the other one (the right fix) and added unit tests |
| 115 |
|
that check the return values (which was not done before). |
| 116 |
|
|
| 117 |
|
21. Several CMake things: |
| 118 |
|
|
| 119 |
|
(1) Arranged that, when cmake is used on Unix, the libraries end up with |
| 120 |
|
the names libpcre and libpcreposix, not just pcre and pcreposix. |
| 121 |
|
|
| 122 |
|
(2) The above change means that pcretest and pcregrep are now correctly |
| 123 |
|
linked with the newly-built libraries, not previously installed ones. |
| 124 |
|
|
| 125 |
|
(3) Added PCRE_SUPPORT_LIBREADLINE, PCRE_SUPPORT_LIBZ, PCRE_SUPPORT_LIBBZ2. |
| 126 |
|
|
| 127 |
|
22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.* |
| 128 |
|
crashed when matching a string such as a\x{2029}b (note that \x{2029} is a |
| 129 |
|
UTF-8 newline character). The key issue is that the pattern starts .*; |
| 130 |
|
this means that the match must be either at the beginning, or after a |
| 131 |
|
newline. The bug was in the code for advancing after a failed match and |
| 132 |
|
checking that the new position followed a newline. It was not taking |
| 133 |
|
account of UTF-8 characters correctly. |
| 134 |
|
|
| 135 |
|
23. PCRE was behaving differently from Perl in the way it recognized POSIX |
| 136 |
|
character classes. PCRE was not treating the sequence [:...:] as a |
| 137 |
|
character class unless the ... were all letters. Perl, however, seems to |
| 138 |
|
allow any characters between [: and :], though of course it rejects as |
| 139 |
|
unknown any "names" that contain non-letters, because all the known class |
| 140 |
|
names consist only of letters. Thus, Perl gives an error for [[:1234:]], |
| 141 |
|
for example, whereas PCRE did not - it did not recognize a POSIX character |
| 142 |
|
class. This seemed a bit dangerous, so the code has been changed to be |
| 143 |
|
closer to Perl. The behaviour is not identical to Perl, because PCRE will |
| 144 |
|
diagnose an unknown class for, for example, [[:l\ower:]] where Perl will |
| 145 |
|
treat it as [[:lower:]]. However, PCRE does now give "unknown" errors where |
| 146 |
|
Perl does, and where it didn't before. |
| 147 |
|
|
| 148 |
|
24. Rewrite so as to remove the single use of %n from pcregrep because in some |
| 149 |
|
Windows environments %n is disabled by default. |
| 150 |
|
|
| 151 |
|
|
| 152 |
Version 7.4 21-Sep-07 |
Version 7.4 21-Sep-07 |