| 1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
| 2 |
------------------ |
------------------ |
| 3 |
|
|
| 4 |
|
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 |
|
3. Applied Christian Ehrlicher's patch to update the CMake build files to |
| 15 |
|
bring them up to date and include new features. This patch includes: |
| 16 |
|
|
| 17 |
|
- Fixed PH's badly added libz and libbz2 support. |
| 18 |
|
- Fixed a problem with static linking. |
| 19 |
|
- Added pcredemo. |
| 20 |
|
- Fixed dftables problem and added an option. |
| 21 |
|
- Added a number of HAVE_XXX tests, including HAVE_WINDOWS_H and |
| 22 |
|
HAVE_LONG_LONG. |
| 23 |
|
- Added readline support for pcretest. |
| 24 |
|
- Added an listing of the option settings after cmake has run. |
| 25 |
|
|
| 26 |
|
4. A user submitted a patch to Makefile that makes it easy to created a dll |
| 27 |
|
under mingw. I added stuff to Makefile.am that cause it to include this |
| 28 |
|
special target, without affecting anything else. |
| 29 |
|
|
| 30 |
|
5. Applied Craig's patch that moves no_arg into the RE class in the C++ code. |
| 31 |
|
This is an attempt to solve the reported problem "pcrecpp::no_arg is not |
| 32 |
|
exported in the Windows port". It has not yet been confirmed that the patch |
| 33 |
|
solves the problem, but it does no harm. |
| 34 |
|
|
| 35 |
|
|
| 36 |
|
Version 7.5 10-Jan-08 |
| 37 |
|
--------------------- |
| 38 |
|
|
| 39 |
|
1. Applied a patch from Craig: "This patch makes it possible to 'ignore' |
| 40 |
|
values in parens when parsing an RE using the C++ wrapper." |
| 41 |
|
|
| 42 |
|
2. Negative specials like \S did not work in character classes in UTF-8 mode. |
| 43 |
|
Characters greater than 255 were excluded from the class instead of being |
| 44 |
|
included. |
| 45 |
|
|
| 46 |
|
3. The same bug as (2) above applied to negated POSIX classes such as |
| 47 |
|
[:^space:]. |
| 48 |
|
|
| 49 |
|
4. PCRECPP_STATIC was referenced in pcrecpp_internal.h, but nowhere was it |
| 50 |
|
defined or documented. It seems to have been a typo for PCRE_STATIC, so |
| 51 |
|
I have changed it. |
| 52 |
|
|
| 53 |
|
5. The construct (?&) was not diagnosed as a syntax error (it referenced the |
| 54 |
|
first named subpattern) and a construct such as (?&a) would reference the |
| 55 |
|
first named subpattern whose name started with "a" (in other words, the |
| 56 |
|
length check was missing). Both these problems are fixed. "Subpattern name |
| 57 |
|
expected" is now given for (?&) (a zero-length name), and this patch also |
| 58 |
|
makes it give the same error for \k'' (previously it complained that that |
| 59 |
|
was a reference to a non-existent subpattern). |
| 60 |
|
|
| 61 |
|
6. The erroneous patterns (?+-a) and (?-+a) give different error messages; |
| 62 |
|
this is right because (?- can be followed by option settings as well as by |
| 63 |
|
digits. I have, however, made the messages clearer. |
| 64 |
|
|
| 65 |
|
7. Patterns such as (?(1)a|b) (a pattern that contains fewer subpatterns |
| 66 |
|
than the number used in the conditional) now cause a compile-time error. |
| 67 |
|
This is actually not compatible with Perl, which accepts such patterns, but |
| 68 |
|
treats the conditional as always being FALSE (as PCRE used to), but it |
| 69 |
|
seems to me that giving a diagnostic is better. |
| 70 |
|
|
| 71 |
|
8. Change "alphameric" to the more common word "alphanumeric" in comments |
| 72 |
|
and messages. |
| 73 |
|
|
| 74 |
|
9. Fix two occurrences of "backslash" in comments that should have been |
| 75 |
|
"backspace". |
| 76 |
|
|
| 77 |
|
10. Remove two redundant lines of code that can never be obeyed (their function |
| 78 |
|
was moved elsewhere). |
| 79 |
|
|
| 80 |
|
11. The program that makes PCRE's Unicode character property table had a bug |
| 81 |
|
which caused it to generate incorrect table entries for sequences of |
| 82 |
|
characters that have the same character type, but are in different scripts. |
| 83 |
|
It amalgamated them into a single range, with the script of the first of |
| 84 |
|
them. In other words, some characters were in the wrong script. There were |
| 85 |
|
thirteen such cases, affecting characters in the following ranges: |
| 86 |
|
|
| 87 |
|
U+002b0 - U+002c1 |
| 88 |
|
U+0060c - U+0060d |
| 89 |
|
U+0061e - U+00612 |
| 90 |
|
U+0064b - U+0065e |
| 91 |
|
U+0074d - U+0076d |
| 92 |
|
U+01800 - U+01805 |
| 93 |
|
U+01d00 - U+01d77 |
| 94 |
|
U+01d9b - U+01dbf |
| 95 |
|
U+0200b - U+0200f |
| 96 |
|
U+030fc - U+030fe |
| 97 |
|
U+03260 - U+0327f |
| 98 |
|
U+0fb46 - U+0fbb1 |
| 99 |
|
U+10450 - U+1049d |
| 100 |
|
|
| 101 |
|
12. The -o option (show only the matching part of a line) for pcregrep was not |
| 102 |
|
compatible with GNU grep in that, if there was more than one match in a |
| 103 |
|
line, it showed only the first of them. It now behaves in the same way as |
| 104 |
|
GNU grep. |
| 105 |
|
|
| 106 |
|
13. If the -o and -v options were combined for pcregrep, it printed a blank |
| 107 |
|
line for every non-matching line. GNU grep prints nothing, and pcregrep now |
| 108 |
|
does the same. The return code can be used to tell if there were any |
| 109 |
|
non-matching lines. |
| 110 |
|
|
| 111 |
|
14. Added --file-offsets and --line-offsets to pcregrep. |
| 112 |
|
|
| 113 |
|
15. The pattern (?=something)(?R) was not being diagnosed as a potentially |
| 114 |
|
infinitely looping recursion. The bug was that positive lookaheads were not |
| 115 |
|
being skipped when checking for a possible empty match (negative lookaheads |
| 116 |
|
and both kinds of lookbehind were skipped). |
| 117 |
|
|
| 118 |
|
16. Fixed two typos in the Windows-only code in pcregrep.c, and moved the |
| 119 |
|
inclusion of <windows.h> to before rather than after the definition of |
| 120 |
|
INVALID_FILE_ATTRIBUTES (patch from David Byron). |
| 121 |
|
|
| 122 |
|
17. Specifying a possessive quantifier with a specific limit for a Unicode |
| 123 |
|
character property caused pcre_compile() to compile bad code, which led at |
| 124 |
|
runtime to PCRE_ERROR_INTERNAL (-14). Examples of patterns that caused this |
| 125 |
|
are: /\p{Zl}{2,3}+/8 and /\p{Cc}{2}+/8. It was the possessive "+" that |
| 126 |
|
caused the error; without that there was no problem. |
| 127 |
|
|
| 128 |
|
18. Added --enable-pcregrep-libz and --enable-pcregrep-libbz2. |
| 129 |
|
|
| 130 |
|
19. Added --enable-pcretest-libreadline. |
| 131 |
|
|
| 132 |
|
20. In pcrecpp.cc, the variable 'count' was incremented twice in |
| 133 |
|
RE::GlobalReplace(). As a result, the number of replacements returned was |
| 134 |
|
double what it should be. I removed one of the increments, but Craig sent a |
| 135 |
|
later patch that removed the other one (the right fix) and added unit tests |
| 136 |
|
that check the return values (which was not done before). |
| 137 |
|
|
| 138 |
|
21. Several CMake things: |
| 139 |
|
|
| 140 |
|
(1) Arranged that, when cmake is used on Unix, the libraries end up with |
| 141 |
|
the names libpcre and libpcreposix, not just pcre and pcreposix. |
| 142 |
|
|
| 143 |
|
(2) The above change means that pcretest and pcregrep are now correctly |
| 144 |
|
linked with the newly-built libraries, not previously installed ones. |
| 145 |
|
|
| 146 |
|
(3) Added PCRE_SUPPORT_LIBREADLINE, PCRE_SUPPORT_LIBZ, PCRE_SUPPORT_LIBBZ2. |
| 147 |
|
|
| 148 |
|
22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.* |
| 149 |
|
crashed when matching a string such as a\x{2029}b (note that \x{2029} is a |
| 150 |
|
UTF-8 newline character). The key issue is that the pattern starts .*; |
| 151 |
|
this means that the match must be either at the beginning, or after a |
| 152 |
|
newline. The bug was in the code for advancing after a failed match and |
| 153 |
|
checking that the new position followed a newline. It was not taking |
| 154 |
|
account of UTF-8 characters correctly. |
| 155 |
|
|
| 156 |
|
23. PCRE was behaving differently from Perl in the way it recognized POSIX |
| 157 |
|
character classes. PCRE was not treating the sequence [:...:] as a |
| 158 |
|
character class unless the ... were all letters. Perl, however, seems to |
| 159 |
|
allow any characters between [: and :], though of course it rejects as |
| 160 |
|
unknown any "names" that contain non-letters, because all the known class |
| 161 |
|
names consist only of letters. Thus, Perl gives an error for [[:1234:]], |
| 162 |
|
for example, whereas PCRE did not - it did not recognize a POSIX character |
| 163 |
|
class. This seemed a bit dangerous, so the code has been changed to be |
| 164 |
|
closer to Perl. The behaviour is not identical to Perl, because PCRE will |
| 165 |
|
diagnose an unknown class for, for example, [[:l\ower:]] where Perl will |
| 166 |
|
treat it as [[:lower:]]. However, PCRE does now give "unknown" errors where |
| 167 |
|
Perl does, and where it didn't before. |
| 168 |
|
|
| 169 |
|
24. Rewrite so as to remove the single use of %n from pcregrep because in some |
| 170 |
|
Windows environments %n is disabled by default. |
| 171 |
|
|
| 172 |
|
|
| 173 |
|
Version 7.4 21-Sep-07 |
| 174 |
|
--------------------- |
| 175 |
|
|
| 176 |
|
1. Change 7.3/28 was implemented for classes by looking at the bitmap. This |
| 177 |
|
means that a class such as [\s] counted as "explicit reference to CR or |
| 178 |
|
LF". That isn't really right - the whole point of the change was to try to |
| 179 |
|
help when there was an actual mention of one of the two characters. So now |
| 180 |
|
the change happens only if \r or \n (or a literal CR or LF) character is |
| 181 |
|
encountered. |
| 182 |
|
|
| 183 |
|
2. The 32-bit options word was also used for 6 internal flags, but the numbers |
| 184 |
|
of both had grown to the point where there were only 3 bits left. |
| 185 |
|
Fortunately, there was spare space in the data structure, and so I have |
| 186 |
|
moved the internal flags into a new 16-bit field to free up more option |
| 187 |
|
bits. |
| 188 |
|
|
| 189 |
|
3. The appearance of (?J) at the start of a pattern set the DUPNAMES option, |
| 190 |
|
but did not set the internal JCHANGED flag - either of these is enough to |
| 191 |
|
control the way the "get" function works - but the PCRE_INFO_JCHANGED |
| 192 |
|
facility is supposed to tell if (?J) was ever used, so now (?J) at the |
| 193 |
|
start sets both bits. |
| 194 |
|
|
| 195 |
|
4. Added options (at build time, compile time, exec time) to change \R from |
| 196 |
|
matching any Unicode line ending sequence to just matching CR, LF, or CRLF. |
| 197 |
|
|
| 198 |
|
5. doc/pcresyntax.html was missing from the distribution. |
| 199 |
|
|
| 200 |
|
6. Put back the definition of PCRE_ERROR_NULLWSLIMIT, for backward |
| 201 |
|
compatibility, even though it is no longer used. |
| 202 |
|
|
| 203 |
|
7. Added macro for snprintf to pcrecpp_unittest.cc and also for strtoll and |
| 204 |
|
strtoull to pcrecpp.cc to select the available functions in WIN32 when the |
| 205 |
|
windows.h file is present (where different names are used). [This was |
| 206 |
|
reversed later after testing - see 16 below.] |
| 207 |
|
|
| 208 |
|
8. Changed all #include <config.h> to #include "config.h". There were also |
| 209 |
|
some further <pcre.h> cases that I changed to "pcre.h". |
| 210 |
|
|
| 211 |
|
9. When pcregrep was used with the --colour option, it missed the line ending |
| 212 |
|
sequence off the lines that it output. |
| 213 |
|
|
| 214 |
|
10. It was pointed out to me that arrays of string pointers cause lots of |
| 215 |
|
relocations when a shared library is dynamically loaded. A technique of |
| 216 |
|
using a single long string with a table of offsets can drastically reduce |
| 217 |
|
these. I have refactored PCRE in four places to do this. The result is |
| 218 |
|
dramatic: |
| 219 |
|
|
| 220 |
|
Originally: 290 |
| 221 |
|
After changing UCP table: 187 |
| 222 |
|
After changing error message table: 43 |
| 223 |
|
After changing table of "verbs" 36 |
| 224 |
|
After changing table of Posix names 22 |
| 225 |
|
|
| 226 |
|
Thanks to the folks working on Gregex for glib for this insight. |
| 227 |
|
|
| 228 |
|
11. --disable-stack-for-recursion caused compiling to fail unless -enable- |
| 229 |
|
unicode-properties was also set. |
| 230 |
|
|
| 231 |
|
12. Updated the tests so that they work when \R is defaulted to ANYCRLF. |
| 232 |
|
|
| 233 |
|
13. Added checks for ANY and ANYCRLF to pcrecpp.cc where it previously |
| 234 |
|
checked only for CRLF. |
| 235 |
|
|
| 236 |
|
14. Added casts to pcretest.c to avoid compiler warnings. |
| 237 |
|
|
| 238 |
|
15. Added Craig's patch to various pcrecpp modules to avoid compiler warnings. |
| 239 |
|
|
| 240 |
|
16. Added Craig's patch to remove the WINDOWS_H tests, that were not working, |
| 241 |
|
and instead check for _strtoi64 explicitly, and avoid the use of snprintf() |
| 242 |
|
entirely. This removes changes made in 7 above. |
| 243 |
|
|
| 244 |
|
17. The CMake files have been updated, and there is now more information about |
| 245 |
|
building with CMake in the NON-UNIX-USE document. |
| 246 |
|
|
| 247 |
|
|
| 248 |
Version 7.3 28-Aug-07 |
Version 7.3 28-Aug-07 |
| 249 |
--------------------- |
--------------------- |
| 250 |
|
|
Parent Directory
| 
Revision Log
| 
Patch