1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
2 |
------------------ |
------------------ |
3 |
|
|
4 |
Version 7.5 12-Nov-07 |
Version 7.8 25-Aug-08 |
5 |
|
--------------------- |
6 |
|
|
7 |
|
1. Replaced UCP searching code with optimized version as implemented for Ad |
8 |
|
Muncher (http://www.admuncher.com/) by Peter Kankowski. This uses a two- |
9 |
|
stage table and inline lookup instead of a function, giving speed ups of 2 |
10 |
|
to 5 times on some simple patterns that I tested. Permission was given to |
11 |
|
distribute the MultiStage2.py script that generates the tables (it's not in |
12 |
|
the tarball, but is in the Subversion repository). |
13 |
|
|
14 |
|
2. Updated the Unicode datatables to Unicode 5.1.0. This adds yet more |
15 |
|
scripts. |
16 |
|
|
17 |
|
3. Change 12 for 7.7 introduced a bug in pcre_study() when a pattern contained |
18 |
|
a group with a zero qualifier. The result of the study could be incorrect, |
19 |
|
or the function might crash, depending on the pattern. |
20 |
|
|
21 |
|
4. Caseless matching was not working for non-ASCII characters in back |
22 |
|
references. For example, /(\x{de})\1/8i was not matching \x{de}\x{fe}. |
23 |
|
It now works when Unicode Property Support is available. |
24 |
|
|
25 |
|
5. In pcretest, an escape such as \x{de} in the data was always generating |
26 |
|
a UTF-8 string, even in non-UTF-8 mode. Now it generates a single byte in |
27 |
|
non-UTF-8 mode. If the value is greater than 255, it gives a warning about |
28 |
|
truncation. |
29 |
|
|
30 |
|
6. Minor bugfix in pcrecpp.cc (change "" == ... to NULL == ...). |
31 |
|
|
32 |
|
7. Added two (int) casts to pcregrep when printing the difference of two |
33 |
|
pointers, in case they are 64-bit values. |
34 |
|
|
35 |
|
8. Added comments about Mac OS X stack usage to the pcrestack man page and to |
36 |
|
test 2 if it fails. |
37 |
|
|
38 |
|
9. Added PCRE_CALL_CONVENTION just before the names of all exported functions, |
39 |
|
and a #define of that name to empty if it is not externally set. This is to |
40 |
|
allow users of MSVC to set it if necessary. |
41 |
|
|
42 |
|
10. The PCRE_EXP_DEFN macro which precedes exported functions was missing from |
43 |
|
the convenience functions in the pcre_get.c source file. |
44 |
|
|
45 |
|
11. An option change at the start of a pattern that had top-level alternatives |
46 |
|
could cause overwriting and/or a crash. This command provoked a crash in |
47 |
|
some environments: |
48 |
|
|
49 |
|
printf "/(?i)[\xc3\xa9\xc3\xbd]|[\xc3\xa9\xc3\xbdA]/8\n" | pcretest |
50 |
|
|
51 |
|
This potential security problem was recorded as CVE-2008-2371. |
52 |
|
|
53 |
|
12. For a pattern where the match had to start at the beginning or immediately |
54 |
|
after a newline (e.g /.*anything/ without the DOTALL flag), pcre_exec() and |
55 |
|
pcre_dfa_exec() could read past the end of the passed subject if there was |
56 |
|
no match. To help with detecting such bugs (e.g. with valgrind), I modified |
57 |
|
pcretest so that it places the subject at the end of its malloc-ed buffer. |
58 |
|
|
59 |
|
13. The change to pcretest in 12 above threw up a couple more cases when pcre_ |
60 |
|
exec() might read past the end of the data buffer in UTF-8 mode. |
61 |
|
|
62 |
|
14. A similar bug to 7.3/2 existed when the PCRE_FIRSTLINE option was set and |
63 |
|
the data contained the byte 0x85 as part of a UTF-8 character within its |
64 |
|
first line. This applied both to normal and DFA matching. |
65 |
|
|
66 |
|
15. Lazy qualifiers were not working in some cases in UTF-8 mode. For example, |
67 |
|
/^[^d]*?$/8 failed to match "abc". |
68 |
|
|
69 |
|
16. Added a missing copyright notice to pcrecpp_internal.h. |
70 |
|
|
71 |
|
17. Make it more clear in the documentation that values returned from |
72 |
|
pcre_exec() in ovector are byte offsets, not character counts. |
73 |
|
|
74 |
|
|
75 |
|
Version 7.7 07-May-08 |
76 |
|
--------------------- |
77 |
|
|
78 |
|
1. Applied Craig's patch to sort out a long long problem: "If we can't convert |
79 |
|
a string to a long long, pretend we don't even have a long long." This is |
80 |
|
done by checking for the strtoq, strtoll, and _strtoi64 functions. |
81 |
|
|
82 |
|
2. Applied Craig's patch to pcrecpp.cc to restore ABI compatibility with |
83 |
|
pre-7.6 versions, which defined a global no_arg variable instead of putting |
84 |
|
it in the RE class. (See also #8 below.) |
85 |
|
|
86 |
|
3. Remove a line of dead code, identified by coverity and reported by Nuno |
87 |
|
Lopes. |
88 |
|
|
89 |
|
4. Fixed two related pcregrep bugs involving -r with --include or --exclude: |
90 |
|
|
91 |
|
(1) The include/exclude patterns were being applied to the whole pathnames |
92 |
|
of files, instead of just to the final components. |
93 |
|
|
94 |
|
(2) If there was more than one level of directory, the subdirectories were |
95 |
|
skipped unless they satisfied the include/exclude conditions. This is |
96 |
|
inconsistent with GNU grep (and could even be seen as contrary to the |
97 |
|
pcregrep specification - which I improved to make it absolutely clear). |
98 |
|
The action now is always to scan all levels of directory, and just |
99 |
|
apply the include/exclude patterns to regular files. |
100 |
|
|
101 |
|
5. Added the --include_dir and --exclude_dir patterns to pcregrep, and used |
102 |
|
--exclude_dir in the tests to avoid scanning .svn directories. |
103 |
|
|
104 |
|
6. Applied Craig's patch to the QuoteMeta function so that it escapes the |
105 |
|
NUL character as backslash + 0 rather than backslash + NUL, because PCRE |
106 |
|
doesn't support NULs in patterns. |
107 |
|
|
108 |
|
7. Added some missing "const"s to declarations of static tables in |
109 |
|
pcre_compile.c and pcre_dfa_exec.c. |
110 |
|
|
111 |
|
8. Applied Craig's patch to pcrecpp.cc to fix a problem in OS X that was |
112 |
|
caused by fix #2 above. (Subsequently also a second patch to fix the |
113 |
|
first patch. And a third patch - this was a messy problem.) |
114 |
|
|
115 |
|
9. Applied Craig's patch to remove the use of push_back(). |
116 |
|
|
117 |
|
10. Applied Alan Lehotsky's patch to add REG_STARTEND support to the POSIX |
118 |
|
matching function regexec(). |
119 |
|
|
120 |
|
11. Added support for the Oniguruma syntax \g<name>, \g<n>, \g'name', \g'n', |
121 |
|
which, however, unlike Perl's \g{...}, are subroutine calls, not back |
122 |
|
references. PCRE supports relative numbers with this syntax (I don't think |
123 |
|
Oniguruma does). |
124 |
|
|
125 |
|
12. Previously, a group with a zero repeat such as (...){0} was completely |
126 |
|
omitted from the compiled regex. However, this means that if the group |
127 |
|
was called as a subroutine from elsewhere in the pattern, things went wrong |
128 |
|
(an internal error was given). Such groups are now left in the compiled |
129 |
|
pattern, with a new opcode that causes them to be skipped at execution |
130 |
|
time. |
131 |
|
|
132 |
|
13. Added the PCRE_JAVASCRIPT_COMPAT option. This makes the following changes |
133 |
|
to the way PCRE behaves: |
134 |
|
|
135 |
|
(a) A lone ] character is dis-allowed (Perl treats it as data). |
136 |
|
|
137 |
|
(b) A back reference to an unmatched subpattern matches an empty string |
138 |
|
(Perl fails the current match path). |
139 |
|
|
140 |
|
(c) A data ] in a character class must be notated as \] because if the |
141 |
|
first data character in a class is ], it defines an empty class. (In |
142 |
|
Perl it is not possible to have an empty class.) The empty class [] |
143 |
|
never matches; it forces failure and is equivalent to (*FAIL) or (?!). |
144 |
|
The negative empty class [^] matches any one character, independently |
145 |
|
of the DOTALL setting. |
146 |
|
|
147 |
|
14. A pattern such as /(?2)[]a()b](abc)/ which had a forward reference to a |
148 |
|
non-existent subpattern following a character class starting with ']' and |
149 |
|
containing () gave an internal compiling error instead of "reference to |
150 |
|
non-existent subpattern". Fortunately, when the pattern did exist, the |
151 |
|
compiled code was correct. (When scanning forwards to check for the |
152 |
|
existencd of the subpattern, it was treating the data ']' as terminating |
153 |
|
the class, so got the count wrong. When actually compiling, the reference |
154 |
|
was subsequently set up correctly.) |
155 |
|
|
156 |
|
15. The "always fail" assertion (?!) is optimzed to (*FAIL) by pcre_compile; |
157 |
|
it was being rejected as not supported by pcre_dfa_exec(), even though |
158 |
|
other assertions are supported. I have made pcre_dfa_exec() support |
159 |
|
(*FAIL). |
160 |
|
|
161 |
|
16. The implementation of 13c above involved the invention of a new opcode, |
162 |
|
OP_ALLANY, which is like OP_ANY but doesn't check the /s flag. Since /s |
163 |
|
cannot be changed at match time, I realized I could make a small |
164 |
|
improvement to matching performance by compiling OP_ALLANY instead of |
165 |
|
OP_ANY for "." when DOTALL was set, and then removing the runtime tests |
166 |
|
on the OP_ANY path. |
167 |
|
|
168 |
|
17. Compiling pcretest on Windows with readline support failed without the |
169 |
|
following two fixes: (1) Make the unistd.h include conditional on |
170 |
|
HAVE_UNISTD_H; (2) #define isatty and fileno as _isatty and _fileno. |
171 |
|
|
172 |
|
18. Changed CMakeLists.txt and cmake/FindReadline.cmake to arrange for the |
173 |
|
ncurses library to be included for pcretest when ReadLine support is |
174 |
|
requested, but also to allow for it to be overridden. This patch came from |
175 |
|
Daniel Bergström. |
176 |
|
|
177 |
|
19. There was a typo in the file ucpinternal.h where f0_rangeflag was defined |
178 |
|
as 0x00f00000 instead of 0x00800000. Luckily, this would not have caused |
179 |
|
any errors with the current Unicode tables. Thanks to Peter Kankowski for |
180 |
|
spotting this. |
181 |
|
|
182 |
|
|
183 |
|
Version 7.6 28-Jan-08 |
184 |
|
--------------------- |
185 |
|
|
186 |
|
1. A character class containing a very large number of characters with |
187 |
|
codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer |
188 |
|
overflow. |
189 |
|
|
190 |
|
2. Patch to cut out the "long long" test in pcrecpp_unittest when |
191 |
|
HAVE_LONG_LONG is not defined. |
192 |
|
|
193 |
|
3. Applied Christian Ehrlicher's patch to update the CMake build files to |
194 |
|
bring them up to date and include new features. This patch includes: |
195 |
|
|
196 |
|
- Fixed PH's badly added libz and libbz2 support. |
197 |
|
- Fixed a problem with static linking. |
198 |
|
- Added pcredemo. [But later removed - see 7 below.] |
199 |
|
- Fixed dftables problem and added an option. |
200 |
|
- Added a number of HAVE_XXX tests, including HAVE_WINDOWS_H and |
201 |
|
HAVE_LONG_LONG. |
202 |
|
- Added readline support for pcretest. |
203 |
|
- Added an listing of the option settings after cmake has run. |
204 |
|
|
205 |
|
4. A user submitted a patch to Makefile that makes it easy to create |
206 |
|
"pcre.dll" under mingw when using Configure/Make. I added stuff to |
207 |
|
Makefile.am that cause it to include this special target, without |
208 |
|
affecting anything else. Note that the same mingw target plus all |
209 |
|
the other distribution libraries and programs are now supported |
210 |
|
when configuring with CMake (see 6 below) instead of with |
211 |
|
Configure/Make. |
212 |
|
|
213 |
|
5. Applied Craig's patch that moves no_arg into the RE class in the C++ code. |
214 |
|
This is an attempt to solve the reported problem "pcrecpp::no_arg is not |
215 |
|
exported in the Windows port". It has not yet been confirmed that the patch |
216 |
|
solves the problem, but it does no harm. |
217 |
|
|
218 |
|
6. Applied Sheri's patch to CMakeLists.txt to add NON_STANDARD_LIB_PREFIX and |
219 |
|
NON_STANDARD_LIB_SUFFIX for dll names built with mingw when configured |
220 |
|
with CMake, and also correct the comment about stack recursion. |
221 |
|
|
222 |
|
7. Remove the automatic building of pcredemo from the ./configure system and |
223 |
|
from CMakeLists.txt. The whole idea of pcredemo.c is that it is an example |
224 |
|
of a program that users should build themselves after PCRE is installed, so |
225 |
|
building it automatically is not really right. What is more, it gave |
226 |
|
trouble in some build environments. |
227 |
|
|
228 |
|
8. Further tidies to CMakeLists.txt from Sheri and Christian. |
229 |
|
|
230 |
|
|
231 |
|
Version 7.5 10-Jan-08 |
232 |
--------------------- |
--------------------- |
233 |
|
|
234 |
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' |
235 |
values in parens when parsing an RE using the C++ wrapper." |
values in parens when parsing an RE using the C++ wrapper." |
236 |
|
|
237 |
2. Negative specials like \S did not work in character classes in UTF-8 mode. |
2. Negative specials like \S did not work in character classes in UTF-8 mode. |
238 |
Characters greater than 255 were excluded from the class instead of being |
Characters greater than 255 were excluded from the class instead of being |
239 |
included. |
included. |
240 |
|
|
241 |
3. The same bug as (2) above applied to negated POSIX classes such as |
3. The same bug as (2) above applied to negated POSIX classes such as |
242 |
[:^space:]. |
[:^space:]. |
243 |
|
|
244 |
4. PCRECPP_STATIC was referenced in pcrecpp_internal.h, but nowhere was it |
4. PCRECPP_STATIC was referenced in pcrecpp_internal.h, but nowhere was it |
245 |
defined or documented. It seems to have been a typo for PCRE_STATIC, so |
defined or documented. It seems to have been a typo for PCRE_STATIC, so |
246 |
I have changed it. |
I have changed it. |
247 |
|
|
248 |
|
5. The construct (?&) was not diagnosed as a syntax error (it referenced the |
249 |
|
first named subpattern) and a construct such as (?&a) would reference the |
250 |
|
first named subpattern whose name started with "a" (in other words, the |
251 |
|
length check was missing). Both these problems are fixed. "Subpattern name |
252 |
|
expected" is now given for (?&) (a zero-length name), and this patch also |
253 |
|
makes it give the same error for \k'' (previously it complained that that |
254 |
|
was a reference to a non-existent subpattern). |
255 |
|
|
256 |
|
6. The erroneous patterns (?+-a) and (?-+a) give different error messages; |
257 |
|
this is right because (?- can be followed by option settings as well as by |
258 |
|
digits. I have, however, made the messages clearer. |
259 |
|
|
260 |
|
7. Patterns such as (?(1)a|b) (a pattern that contains fewer subpatterns |
261 |
|
than the number used in the conditional) now cause a compile-time error. |
262 |
|
This is actually not compatible with Perl, which accepts such patterns, but |
263 |
|
treats the conditional as always being FALSE (as PCRE used to), but it |
264 |
|
seems to me that giving a diagnostic is better. |
265 |
|
|
266 |
|
8. Change "alphameric" to the more common word "alphanumeric" in comments |
267 |
|
and messages. |
268 |
|
|
269 |
|
9. Fix two occurrences of "backslash" in comments that should have been |
270 |
|
"backspace". |
271 |
|
|
272 |
|
10. Remove two redundant lines of code that can never be obeyed (their function |
273 |
|
was moved elsewhere). |
274 |
|
|
275 |
|
11. The program that makes PCRE's Unicode character property table had a bug |
276 |
|
which caused it to generate incorrect table entries for sequences of |
277 |
|
characters that have the same character type, but are in different scripts. |
278 |
|
It amalgamated them into a single range, with the script of the first of |
279 |
|
them. In other words, some characters were in the wrong script. There were |
280 |
|
thirteen such cases, affecting characters in the following ranges: |
281 |
|
|
282 |
|
U+002b0 - U+002c1 |
283 |
|
U+0060c - U+0060d |
284 |
|
U+0061e - U+00612 |
285 |
|
U+0064b - U+0065e |
286 |
|
U+0074d - U+0076d |
287 |
|
U+01800 - U+01805 |
288 |
|
U+01d00 - U+01d77 |
289 |
|
U+01d9b - U+01dbf |
290 |
|
U+0200b - U+0200f |
291 |
|
U+030fc - U+030fe |
292 |
|
U+03260 - U+0327f |
293 |
|
U+0fb46 - U+0fbb1 |
294 |
|
U+10450 - U+1049d |
295 |
|
|
296 |
|
12. The -o option (show only the matching part of a line) for pcregrep was not |
297 |
|
compatible with GNU grep in that, if there was more than one match in a |
298 |
|
line, it showed only the first of them. It now behaves in the same way as |
299 |
|
GNU grep. |
300 |
|
|
301 |
|
13. If the -o and -v options were combined for pcregrep, it printed a blank |
302 |
|
line for every non-matching line. GNU grep prints nothing, and pcregrep now |
303 |
|
does the same. The return code can be used to tell if there were any |
304 |
|
non-matching lines. |
305 |
|
|
306 |
|
14. Added --file-offsets and --line-offsets to pcregrep. |
307 |
|
|
308 |
|
15. The pattern (?=something)(?R) was not being diagnosed as a potentially |
309 |
|
infinitely looping recursion. The bug was that positive lookaheads were not |
310 |
|
being skipped when checking for a possible empty match (negative lookaheads |
311 |
|
and both kinds of lookbehind were skipped). |
312 |
|
|
313 |
|
16. Fixed two typos in the Windows-only code in pcregrep.c, and moved the |
314 |
|
inclusion of <windows.h> to before rather than after the definition of |
315 |
|
INVALID_FILE_ATTRIBUTES (patch from David Byron). |
316 |
|
|
317 |
|
17. Specifying a possessive quantifier with a specific limit for a Unicode |
318 |
|
character property caused pcre_compile() to compile bad code, which led at |
319 |
|
runtime to PCRE_ERROR_INTERNAL (-14). Examples of patterns that caused this |
320 |
|
are: /\p{Zl}{2,3}+/8 and /\p{Cc}{2}+/8. It was the possessive "+" that |
321 |
|
caused the error; without that there was no problem. |
322 |
|
|
323 |
|
18. Added --enable-pcregrep-libz and --enable-pcregrep-libbz2. |
324 |
|
|
325 |
|
19. Added --enable-pcretest-libreadline. |
326 |
|
|
327 |
|
20. In pcrecpp.cc, the variable 'count' was incremented twice in |
328 |
|
RE::GlobalReplace(). As a result, the number of replacements returned was |
329 |
|
double what it should be. I removed one of the increments, but Craig sent a |
330 |
|
later patch that removed the other one (the right fix) and added unit tests |
331 |
|
that check the return values (which was not done before). |
332 |
|
|
333 |
|
21. Several CMake things: |
334 |
|
|
335 |
|
(1) Arranged that, when cmake is used on Unix, the libraries end up with |
336 |
|
the names libpcre and libpcreposix, not just pcre and pcreposix. |
337 |
|
|
338 |
|
(2) The above change means that pcretest and pcregrep are now correctly |
339 |
|
linked with the newly-built libraries, not previously installed ones. |
340 |
|
|
341 |
|
(3) Added PCRE_SUPPORT_LIBREADLINE, PCRE_SUPPORT_LIBZ, PCRE_SUPPORT_LIBBZ2. |
342 |
|
|
343 |
|
22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.* |
344 |
|
crashed when matching a string such as a\x{2029}b (note that \x{2029} is a |
345 |
|
UTF-8 newline character). The key issue is that the pattern starts .*; |
346 |
|
this means that the match must be either at the beginning, or after a |
347 |
|
newline. The bug was in the code for advancing after a failed match and |
348 |
|
checking that the new position followed a newline. It was not taking |
349 |
|
account of UTF-8 characters correctly. |
350 |
|
|
351 |
|
23. PCRE was behaving differently from Perl in the way it recognized POSIX |
352 |
|
character classes. PCRE was not treating the sequence [:...:] as a |
353 |
|
character class unless the ... were all letters. Perl, however, seems to |
354 |
|
allow any characters between [: and :], though of course it rejects as |
355 |
|
unknown any "names" that contain non-letters, because all the known class |
356 |
|
names consist only of letters. Thus, Perl gives an error for [[:1234:]], |
357 |
|
for example, whereas PCRE did not - it did not recognize a POSIX character |
358 |
|
class. This seemed a bit dangerous, so the code has been changed to be |
359 |
|
closer to Perl. The behaviour is not identical to Perl, because PCRE will |
360 |
|
diagnose an unknown class for, for example, [[:l\ower:]] where Perl will |
361 |
|
treat it as [[:lower:]]. However, PCRE does now give "unknown" errors where |
362 |
|
Perl does, and where it didn't before. |
363 |
|
|
364 |
|
24. Rewrite so as to remove the single use of %n from pcregrep because in some |
365 |
|
Windows environments %n is disabled by default. |
366 |
|
|
367 |
|
|
368 |
Version 7.4 21-Sep-07 |
Version 7.4 21-Sep-07 |