1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
2 |
------------------ |
------------------ |
3 |
|
|
4 |
Version 8.11 10-Oct-2010 |
Version 8.32 |
5 |
|
------------ |
6 |
|
|
7 |
|
1. Improved JIT compiler optimizations for first character search and single |
8 |
|
character iterators. |
9 |
|
|
10 |
|
2. Supporting IBM XL C compilers for PPC architectures in the JIT compiler. |
11 |
|
Patch by Daniel Richard G. |
12 |
|
|
13 |
|
3. Single character iterator optimizations in the JIT compiler. |
14 |
|
|
15 |
|
4. Improved JIT compiler optimizations for character ranges. |
16 |
|
|
17 |
|
5. Rename the "leave" variable names to "quit" to improve WinCE compatibility. |
18 |
|
Reported by Giuseppe D'Angelo. |
19 |
|
|
20 |
|
6. The PCRE_STARTLINE bit, indicating that a match can occur only at the start |
21 |
|
of a line, was being set incorrectly in cases where .* appeared inside |
22 |
|
atomic brackets at the start of a pattern, or where there was a subsequent |
23 |
|
*PRUNE or *SKIP. |
24 |
|
|
25 |
|
7. Improved instruction cache flush for POWER/PowerPC. |
26 |
|
Patch by Daniel Richard G. |
27 |
|
|
28 |
|
8. Fixed a number of issues in pcregrep, making it more compatible with GNU |
29 |
|
grep: |
30 |
|
|
31 |
|
(a) There is now no limit to the number of patterns to be matched. |
32 |
|
|
33 |
|
(b) An error is given if a pattern is too long. |
34 |
|
|
35 |
|
(c) Multiple uses of --exclude, --exclude-dir, --include, and --include-dir |
36 |
|
are now supported. |
37 |
|
|
38 |
|
(d) --exclude-from and --include-from (multiple use) have been added. |
39 |
|
|
40 |
|
(e) Exclusions and inclusions now apply to all files and directories, not |
41 |
|
just to those obtained from scanning a directory recursively. |
42 |
|
|
43 |
|
(f) Multiple uses of -f and --file-list are now supported. |
44 |
|
|
45 |
|
(g) In a Windows environment, the default for -d has been changed from |
46 |
|
"read" (the GNU grep default) to "skip", because otherwise the presence |
47 |
|
of a directory in the file list provokes an error. |
48 |
|
|
49 |
|
(h) The documentation has been revised and clarified in places. |
50 |
|
|
51 |
|
9. Improve the matching speed of capturing brackets. |
52 |
|
|
53 |
|
10. Changed the meaning of \X so that it now matches a Unicode extended |
54 |
|
grapheme cluster. |
55 |
|
|
56 |
|
11. Patch by Daniel Richard G to the autoconf files to add a macro for sorting |
57 |
|
out POSIX threads when JIT support is configured. |
58 |
|
|
59 |
|
12. Added support for PCRE_STUDY_EXTRA_NEEDED. |
60 |
|
|
61 |
|
13. In the POSIX wrapper regcomp() function, setting re_nsub field in the preg |
62 |
|
structure could go wrong in environments where size_t is not the same size |
63 |
|
as int. |
64 |
|
|
65 |
|
14. Applied user-supplied patch to pcrecpp.cc to allow PCRE_NO_UTF8_CHECK to be |
66 |
|
set. |
67 |
|
|
68 |
|
15. The EBCDIC support had decayed; later updates to the code had included |
69 |
|
explicit references to (e.g.) \x0a instead of CHAR_LF. There has been a |
70 |
|
general tidy up of EBCDIC-related issues, and the documentation was also |
71 |
|
not quite right. There is now a test that can be run on ASCII systems to |
72 |
|
check some of the EBCDIC-related things (but is it not a full test). |
73 |
|
|
74 |
|
|
75 |
|
|
76 |
|
Version 8.31 06-July-2012 |
77 |
|
------------------------- |
78 |
|
|
79 |
|
1. Fixing a wrong JIT test case and some compiler warnings. |
80 |
|
|
81 |
|
2. Removed a bashism from the RunTest script. |
82 |
|
|
83 |
|
3. Add a cast to pcre_exec.c to fix the warning "unary minus operator applied |
84 |
|
to unsigned type, result still unsigned" that was given by an MS compiler |
85 |
|
on encountering the code "-sizeof(xxx)". |
86 |
|
|
87 |
|
4. Partial matching support is added to the JIT compiler. |
88 |
|
|
89 |
|
5. Fixed several bugs concerned with partial matching of items that consist |
90 |
|
of more than one character: |
91 |
|
|
92 |
|
(a) /^(..)\1/ did not partially match "aba" because checking references was |
93 |
|
done on an "all or nothing" basis. This also applied to repeated |
94 |
|
references. |
95 |
|
|
96 |
|
(b) \R did not give a hard partial match if \r was found at the end of the |
97 |
|
subject. |
98 |
|
|
99 |
|
(c) \X did not give a hard partial match after matching one or more |
100 |
|
characters at the end of the subject. |
101 |
|
|
102 |
|
(d) When newline was set to CRLF, a pattern such as /a$/ did not recognize |
103 |
|
a partial match for the string "\r". |
104 |
|
|
105 |
|
(e) When newline was set to CRLF, the metacharacter "." did not recognize |
106 |
|
a partial match for a CR character at the end of the subject string. |
107 |
|
|
108 |
|
6. If JIT is requested using /S++ or -s++ (instead of just /S+ or -s+) when |
109 |
|
running pcretest, the text "(JIT)" added to the output whenever JIT is |
110 |
|
actually used to run the match. |
111 |
|
|
112 |
|
7. Individual JIT compile options can be set in pcretest by following -s+[+] |
113 |
|
or /S+[+] with a digit between 1 and 7. |
114 |
|
|
115 |
|
8. OP_NOT now supports any UTF character not just single-byte ones. |
116 |
|
|
117 |
|
9. (*MARK) control verb is now supported by the JIT compiler. |
118 |
|
|
119 |
|
10. The command "./RunTest list" lists the available tests without actually |
120 |
|
running any of them. (Because I keep forgetting what they all are.) |
121 |
|
|
122 |
|
11. Add PCRE_INFO_MAXLOOKBEHIND. |
123 |
|
|
124 |
|
12. Applied a (slightly modified) user-supplied patch that improves performance |
125 |
|
when the heap is used for recursion (compiled with --disable-stack-for- |
126 |
|
recursion). Instead of malloc and free for each heap frame each time a |
127 |
|
logical recursion happens, frames are retained on a chain and re-used where |
128 |
|
possible. This sometimes gives as much as 30% improvement. |
129 |
|
|
130 |
|
13. As documented, (*COMMIT) is now confined to within a recursive subpattern |
131 |
|
call. |
132 |
|
|
133 |
|
14. As documented, (*COMMIT) is now confined to within a positive assertion. |
134 |
|
|
135 |
|
15. It is now possible to link pcretest with libedit as an alternative to |
136 |
|
libreadline. |
137 |
|
|
138 |
|
16. (*COMMIT) control verb is now supported by the JIT compiler. |
139 |
|
|
140 |
|
17. The Unicode data tables have been updated to Unicode 6.1.0. |
141 |
|
|
142 |
|
18. Added --file-list option to pcregrep. |
143 |
|
|
144 |
|
19. Added binary file support to pcregrep, including the -a, --binary-files, |
145 |
|
-I, and --text options. |
146 |
|
|
147 |
|
20. The madvise function is renamed for posix_madvise for QNX compatibility |
148 |
|
reasons. Fixed by Giuseppe D'Angelo. |
149 |
|
|
150 |
|
21. Fixed a bug for backward assertions with REVERSE 0 in the JIT compiler. |
151 |
|
|
152 |
|
22. Changed the option for creating symbolic links for 16-bit man pages from |
153 |
|
-s to -sf so that re-installing does not cause issues. |
154 |
|
|
155 |
|
23. Support PCRE_NO_START_OPTIMIZE in JIT as (*MARK) support requires it. |
156 |
|
|
157 |
|
24. Fixed a very old bug in pcretest that caused errors with restarted DFA |
158 |
|
matches in certain environments (the workspace was not being correctly |
159 |
|
retained). Also added to pcre_dfa_exec() a simple plausibility check on |
160 |
|
some of the workspace data at the beginning of a restart. |
161 |
|
|
162 |
|
25. \s*\R was auto-possessifying the \s* when it should not, whereas \S*\R |
163 |
|
was not doing so when it should - probably a typo introduced by SVN 528 |
164 |
|
(change 8.10/14). |
165 |
|
|
166 |
|
26. When PCRE_UCP was not set, \w+\x{c4} was incorrectly auto-possessifying the |
167 |
|
\w+ when the character tables indicated that \x{c4} was a word character. |
168 |
|
There were several related cases, all because the tests for doing a table |
169 |
|
lookup were testing for characters less than 127 instead of 255. |
170 |
|
|
171 |
|
27. If a pattern contains capturing parentheses that are not used in a match, |
172 |
|
their slots in the ovector are set to -1. For those that are higher than |
173 |
|
any matched groups, this happens at the end of processing. In the case when |
174 |
|
there were back references that the ovector was too small to contain |
175 |
|
(causing temporary malloc'd memory to be used during matching), and the |
176 |
|
highest capturing number was not used, memory off the end of the ovector |
177 |
|
was incorrectly being set to -1. (It was using the size of the temporary |
178 |
|
memory instead of the true size.) |
179 |
|
|
180 |
|
28. To catch bugs like 27 using valgrind, when pcretest is asked to specify an |
181 |
|
ovector size, it uses memory at the end of the block that it has got. |
182 |
|
|
183 |
|
29. Check for an overlong MARK name and give an error at compile time. The |
184 |
|
limit is 255 for the 8-bit library and 65535 for the 16-bit library. |
185 |
|
|
186 |
|
30. JIT compiler update. |
187 |
|
|
188 |
|
31. JIT is now supported on jailbroken iOS devices. Thanks for Ruiger |
189 |
|
Rill for the patch. |
190 |
|
|
191 |
|
32. Put spaces around SLJIT_PRINT_D in the JIT compiler. Required by CXX11. |
192 |
|
|
193 |
|
33. Variable renamings in the PCRE-JIT compiler. No functionality change. |
194 |
|
|
195 |
|
34. Fixed typos in pcregrep: in two places there was SUPPORT_LIBZ2 instead of |
196 |
|
SUPPORT_LIBBZ2. This caused a build problem when bzip2 but not gzip (zlib) |
197 |
|
was enabled. |
198 |
|
|
199 |
|
35. Improve JIT code generation for greedy plus quantifier. |
200 |
|
|
201 |
|
36. When /((?:a?)*)*c/ or /((?>a?)*)*c/ was matched against "aac", it set group |
202 |
|
1 to "aa" instead of to an empty string. The bug affected repeated groups |
203 |
|
that could potentially match an empty string. |
204 |
|
|
205 |
|
37. Optimizing single character iterators in JIT. |
206 |
|
|
207 |
|
38. Wide characters specified with \uxxxx in JavaScript mode are now subject to |
208 |
|
the same checks as \x{...} characters in non-JavaScript mode. Specifically, |
209 |
|
codepoints that are too big for the mode are faulted, and in a UTF mode, |
210 |
|
disallowed codepoints are also faulted. |
211 |
|
|
212 |
|
39. If PCRE was compiled with UTF support, in three places in the DFA |
213 |
|
matcher there was code that should only have been obeyed in UTF mode, but |
214 |
|
was being obeyed unconditionally. In 8-bit mode this could cause incorrect |
215 |
|
processing when bytes with values greater than 127 were present. In 16-bit |
216 |
|
mode the bug would be provoked by values in the range 0xfc00 to 0xdc00. In |
217 |
|
both cases the values are those that cannot be the first data item in a UTF |
218 |
|
character. The three items that might have provoked this were recursions, |
219 |
|
possessively repeated groups, and atomic groups. |
220 |
|
|
221 |
|
40. Ensure that libpcre is explicitly listed in the link commands for pcretest |
222 |
|
and pcregrep, because some OS require shared objects to be explicitly |
223 |
|
passed to ld, causing the link step to fail if they are not. |
224 |
|
|
225 |
|
41. There were two incorrect #ifdefs in pcre_study.c, meaning that, in 16-bit |
226 |
|
mode, patterns that started with \h* or \R* might be incorrectly matched. |
227 |
|
|
228 |
|
|
229 |
|
Version 8.30 04-February-2012 |
230 |
|
----------------------------- |
231 |
|
|
232 |
|
1. Renamed "isnumber" as "is_a_number" because in some Mac environments this |
233 |
|
name is defined in ctype.h. |
234 |
|
|
235 |
|
2. Fixed a bug in fixed-length calculation for lookbehinds that would show up |
236 |
|
only in quite long subpatterns. |
237 |
|
|
238 |
|
3. Removed the function pcre_info(), which has been obsolete and deprecated |
239 |
|
since it was replaced by pcre_fullinfo() in February 2000. |
240 |
|
|
241 |
|
4. For a non-anchored pattern, if (*SKIP) was given with a name that did not |
242 |
|
match a (*MARK), and the match failed at the start of the subject, a |
243 |
|
reference to memory before the start of the subject could occur. This bug |
244 |
|
was introduced by fix 17 of release 8.21. |
245 |
|
|
246 |
|
5. A reference to an unset group with zero minimum repetition was giving |
247 |
|
totally wrong answers (in non-JavaScript-compatibility mode). For example, |
248 |
|
/(another)?(\1?)test/ matched against "hello world test". This bug was |
249 |
|
introduced in release 8.13. |
250 |
|
|
251 |
|
6. Add support for 16-bit character strings (a large amount of work involving |
252 |
|
many changes and refactorings). |
253 |
|
|
254 |
|
7. RunGrepTest failed on msys because \r\n was replaced by whitespace when the |
255 |
|
command "pattern=`printf 'xxx\r\njkl'`" was run. The pattern is now taken |
256 |
|
from a file. |
257 |
|
|
258 |
|
8. Ovector size of 2 is also supported by JIT based pcre_exec (the ovector size |
259 |
|
rounding is not applied in this particular case). |
260 |
|
|
261 |
|
9. The invalid Unicode surrogate codepoints U+D800 to U+DFFF are now rejected |
262 |
|
if they appear, or are escaped, in patterns. |
263 |
|
|
264 |
|
10. Get rid of a number of -Wunused-but-set-variable warnings. |
265 |
|
|
266 |
|
11. The pattern /(?=(*:x))(q|)/ matches an empty string, and returns the mark |
267 |
|
"x". The similar pattern /(?=(*:x))((*:y)q|)/ did not return a mark at all. |
268 |
|
Oddly, Perl behaves the same way. PCRE has been fixed so that this pattern |
269 |
|
also returns the mark "x". This bug applied to capturing parentheses, |
270 |
|
non-capturing parentheses, and atomic parentheses. It also applied to some |
271 |
|
assertions. |
272 |
|
|
273 |
|
12. Stephen Kelly's patch to CMakeLists.txt allows it to parse the version |
274 |
|
information out of configure.ac instead of relying on pcre.h.generic, which |
275 |
|
is not stored in the repository. |
276 |
|
|
277 |
|
13. Applied Dmitry V. Levin's patch for a more portable method for linking with |
278 |
|
-lreadline. |
279 |
|
|
280 |
|
14. ZH added PCRE_CONFIG_JITTARGET; added its output to pcretest -C. |
281 |
|
|
282 |
|
15. Applied Graycode's patch to put the top-level frame on the stack rather |
283 |
|
than the heap when not using the stack for recursion. This gives a |
284 |
|
performance improvement in many cases when recursion is not deep. |
285 |
|
|
286 |
|
16. Experimental code added to "pcretest -C" to output the stack frame size. |
287 |
|
|
288 |
|
|
289 |
|
Version 8.21 12-Dec-2011 |
290 |
|
------------------------ |
291 |
|
|
292 |
|
1. Updating the JIT compiler. |
293 |
|
|
294 |
|
2. JIT compiler now supports OP_NCREF, OP_RREF and OP_NRREF. New test cases |
295 |
|
are added as well. |
296 |
|
|
297 |
|
3. Fix cache-flush issue on PowerPC (It is still an experimental JIT port). |
298 |
|
PCRE_EXTRA_TABLES is not suported by JIT, and should be checked before |
299 |
|
calling _pcre_jit_exec. Some extra comments are added. |
300 |
|
|
301 |
|
4. (*MARK) settings inside atomic groups that do not contain any capturing |
302 |
|
parentheses, for example, (?>a(*:m)), were not being passed out. This bug |
303 |
|
was introduced by change 18 for 8.20. |
304 |
|
|
305 |
|
5. Supporting of \x, \U and \u in JavaScript compatibility mode based on the |
306 |
|
ECMA-262 standard. |
307 |
|
|
308 |
|
6. Lookbehinds such as (?<=a{2}b) that contained a fixed repetition were |
309 |
|
erroneously being rejected as "not fixed length" if PCRE_CASELESS was set. |
310 |
|
This bug was probably introduced by change 9 of 8.13. |
311 |
|
|
312 |
|
7. While fixing 6 above, I noticed that a number of other items were being |
313 |
|
incorrectly rejected as "not fixed length". This arose partly because newer |
314 |
|
opcodes had not been added to the fixed-length checking code. I have (a) |
315 |
|
corrected the bug and added tests for these items, and (b) arranged for an |
316 |
|
error to occur if an unknown opcode is encountered while checking for fixed |
317 |
|
length instead of just assuming "not fixed length". The items that were |
318 |
|
rejected were: (*ACCEPT), (*COMMIT), (*FAIL), (*MARK), (*PRUNE), (*SKIP), |
319 |
|
(*THEN), \h, \H, \v, \V, and single character negative classes with fixed |
320 |
|
repetitions, e.g. [^a]{3}, with and without PCRE_CASELESS. |
321 |
|
|
322 |
|
8. A possessively repeated conditional subpattern such as (?(?=c)c|d)++ was |
323 |
|
being incorrectly compiled and would have given unpredicatble results. |
324 |
|
|
325 |
|
9. A possessively repeated subpattern with minimum repeat count greater than |
326 |
|
one behaved incorrectly. For example, (A){2,}+ behaved as if it was |
327 |
|
(A)(A)++ which meant that, after a subsequent mismatch, backtracking into |
328 |
|
the first (A) could occur when it should not. |
329 |
|
|
330 |
|
10. Add a cast and remove a redundant test from the code. |
331 |
|
|
332 |
|
11. JIT should use pcre_malloc/pcre_free for allocation. |
333 |
|
|
334 |
|
12. Updated pcre-config so that it no longer shows -L/usr/lib, which seems |
335 |
|
best practice nowadays, and helps with cross-compiling. (If the exec_prefix |
336 |
|
is anything other than /usr, -L is still shown). |
337 |
|
|
338 |
|
13. In non-UTF-8 mode, \C is now supported in lookbehinds and DFA matching. |
339 |
|
|
340 |
|
14. Perl does not support \N without a following name in a [] class; PCRE now |
341 |
|
also gives an error. |
342 |
|
|
343 |
|
15. If a forward reference was repeated with an upper limit of around 2000, |
344 |
|
it caused the error "internal error: overran compiling workspace". The |
345 |
|
maximum number of forward references (including repeats) was limited by the |
346 |
|
internal workspace, and dependent on the LINK_SIZE. The code has been |
347 |
|
rewritten so that the workspace expands (via pcre_malloc) if necessary, and |
348 |
|
the default depends on LINK_SIZE. There is a new upper limit (for safety) |
349 |
|
of around 200,000 forward references. While doing this, I also speeded up |
350 |
|
the filling in of repeated forward references. |
351 |
|
|
352 |
|
16. A repeated forward reference in a pattern such as (a)(?2){2}(.) was |
353 |
|
incorrectly expecting the subject to contain another "a" after the start. |
354 |
|
|
355 |
|
17. When (*SKIP:name) is activated without a corresponding (*MARK:name) earlier |
356 |
|
in the match, the SKIP should be ignored. This was not happening; instead |
357 |
|
the SKIP was being treated as NOMATCH. For patterns such as |
358 |
|
/A(*MARK:A)A+(*SKIP:B)Z|AAC/ this meant that the AAC branch was never |
359 |
|
tested. |
360 |
|
|
361 |
|
18. The behaviour of (*MARK), (*PRUNE), and (*THEN) has been reworked and is |
362 |
|
now much more compatible with Perl, in particular in cases where the result |
363 |
|
is a non-match for a non-anchored pattern. For example, if |
364 |
|
/b(*:m)f|a(*:n)w/ is matched against "abc", the non-match returns the name |
365 |
|
"m", where previously it did not return a name. A side effect of this |
366 |
|
change is that for partial matches, the last encountered mark name is |
367 |
|
returned, as for non matches. A number of tests that were previously not |
368 |
|
Perl-compatible have been moved into the Perl-compatible test files. The |
369 |
|
refactoring has had the pleasing side effect of removing one argument from |
370 |
|
the match() function, thus reducing its stack requirements. |
371 |
|
|
372 |
|
19. If the /S+ option was used in pcretest to study a pattern using JIT, |
373 |
|
subsequent uses of /S (without +) incorrectly behaved like /S+. |
374 |
|
|
375 |
|
21. Retrieve executable code size support for the JIT compiler and fixing |
376 |
|
some warnings. |
377 |
|
|
378 |
|
22. A caseless match of a UTF-8 character whose other case uses fewer bytes did |
379 |
|
not work when the shorter character appeared right at the end of the |
380 |
|
subject string. |
381 |
|
|
382 |
|
23. Added some (int) casts to non-JIT modules to reduce warnings on 64-bit |
383 |
|
systems. |
384 |
|
|
385 |
|
24. Added PCRE_INFO_JITSIZE to pass on the value from (21) above, and also |
386 |
|
output it when the /M option is used in pcretest. |
387 |
|
|
388 |
|
25. The CheckMan script was not being included in the distribution. Also, added |
389 |
|
an explicit "perl" to run Perl scripts from the PrepareRelease script |
390 |
|
because this is reportedly needed in Windows. |
391 |
|
|
392 |
|
26. If study data was being save in a file and studying had not found a set of |
393 |
|
"starts with" bytes for the pattern, the data written to the file (though |
394 |
|
never used) was taken from uninitialized memory and so caused valgrind to |
395 |
|
complain. |
396 |
|
|
397 |
|
27. Updated RunTest.bat as provided by Sheri Pierce. |
398 |
|
|
399 |
|
28. Fixed a possible uninitialized memory bug in pcre_jit_compile.c. |
400 |
|
|
401 |
|
29. Computation of memory usage for the table of capturing group names was |
402 |
|
giving an unnecessarily large value. |
403 |
|
|
404 |
|
|
405 |
|
Version 8.20 21-Oct-2011 |
406 |
|
------------------------ |
407 |
|
|
408 |
|
1. Change 37 of 8.13 broke patterns like [:a]...[b:] because it thought it had |
409 |
|
a POSIX class. After further experiments with Perl, which convinced me that |
410 |
|
Perl has bugs and confusions, a closing square bracket is no longer allowed |
411 |
|
in a POSIX name. This bug also affected patterns with classes that started |
412 |
|
with full stops. |
413 |
|
|
414 |
|
2. If a pattern such as /(a)b|ac/ is matched against "ac", there is no |
415 |
|
captured substring, but while checking the failing first alternative, |
416 |
|
substring 1 is temporarily captured. If the output vector supplied to |
417 |
|
pcre_exec() was not big enough for this capture, the yield of the function |
418 |
|
was still zero ("insufficient space for captured substrings"). This cannot |
419 |
|
be totally fixed without adding another stack variable, which seems a lot |
420 |
|
of expense for a edge case. However, I have improved the situation in cases |
421 |
|
such as /(a)(b)x|abc/ matched against "abc", where the return code |
422 |
|
indicates that fewer than the maximum number of slots in the ovector have |
423 |
|
been set. |
424 |
|
|
425 |
|
3. Related to (2) above: when there are more back references in a pattern than |
426 |
|
slots in the output vector, pcre_exec() uses temporary memory during |
427 |
|
matching, and copies in the captures as far as possible afterwards. It was |
428 |
|
using the entire output vector, but this conflicts with the specification |
429 |
|
that only 2/3 is used for passing back captured substrings. Now it uses |
430 |
|
only the first 2/3, for compatibility. This is, of course, another edge |
431 |
|
case. |
432 |
|
|
433 |
|
4. Zoltan Herczeg's just-in-time compiler support has been integrated into the |
434 |
|
main code base, and can be used by building with --enable-jit. When this is |
435 |
|
done, pcregrep automatically uses it unless --disable-pcregrep-jit or the |
436 |
|
runtime --no-jit option is given. |
437 |
|
|
438 |
|
5. When the number of matches in a pcre_dfa_exec() run exactly filled the |
439 |
|
ovector, the return from the function was zero, implying that there were |
440 |
|
other matches that did not fit. The correct "exactly full" value is now |
441 |
|
returned. |
442 |
|
|
443 |
|
6. If a subpattern that was called recursively or as a subroutine contained |
444 |
|
(*PRUNE) or any other control that caused it to give a non-standard return, |
445 |
|
invalid errors such as "Error -26 (nested recursion at the same subject |
446 |
|
position)" or even infinite loops could occur. |
447 |
|
|
448 |
|
7. If a pattern such as /a(*SKIP)c|b(*ACCEPT)|/ was studied, it stopped |
449 |
|
computing the minimum length on reaching *ACCEPT, and so ended up with the |
450 |
|
wrong value of 1 rather than 0. Further investigation indicates that |
451 |
|
computing a minimum subject length in the presence of *ACCEPT is difficult |
452 |
|
(think back references, subroutine calls), and so I have changed the code |
453 |
|
so that no minimum is registered for a pattern that contains *ACCEPT. |
454 |
|
|
455 |
|
8. If (*THEN) was present in the first (true) branch of a conditional group, |
456 |
|
it was not handled as intended. [But see 16 below.] |
457 |
|
|
458 |
|
9. Replaced RunTest.bat and CMakeLists.txt with improved versions provided by |
459 |
|
Sheri Pierce. |
460 |
|
|
461 |
|
10. A pathological pattern such as /(*ACCEPT)a/ was miscompiled, thinking that |
462 |
|
the first byte in a match must be "a". |
463 |
|
|
464 |
|
11. Change 17 for 8.13 increased the recursion depth for patterns like |
465 |
|
/a(?:.)*?a/ drastically. I've improved things by remembering whether a |
466 |
|
pattern contains any instances of (*THEN). If it does not, the old |
467 |
|
optimizations are restored. It would be nice to do this on a per-group |
468 |
|
basis, but at the moment that is not feasible. |
469 |
|
|
470 |
|
12. In some environments, the output of pcretest -C is CRLF terminated. This |
471 |
|
broke RunTest's code that checks for the link size. A single white space |
472 |
|
character after the value is now allowed for. |
473 |
|
|
474 |
|
13. RunTest now checks for the "fr" locale as well as for "fr_FR" and "french". |
475 |
|
For "fr", it uses the Windows-specific input and output files. |
476 |
|
|
477 |
|
14. If (*THEN) appeared in a group that was called recursively or as a |
478 |
|
subroutine, it did not work as intended. [But see next item.] |
479 |
|
|
480 |
|
15. Consider the pattern /A (B(*THEN)C) | D/ where A, B, C, and D are complex |
481 |
|
pattern fragments (but not containing any | characters). If A and B are |
482 |
|
matched, but there is a failure in C so that it backtracks to (*THEN), PCRE |
483 |
|
was behaving differently to Perl. PCRE backtracked into A, but Perl goes to |
484 |
|
D. In other words, Perl considers parentheses that do not contain any | |
485 |
|
characters to be part of a surrounding alternative, whereas PCRE was |
486 |
|
treading (B(*THEN)C) the same as (B(*THEN)C|(*FAIL)) -- which Perl handles |
487 |
|
differently. PCRE now behaves in the same way as Perl, except in the case |
488 |
|
of subroutine/recursion calls such as (?1) which have in any case always |
489 |
|
been different (but PCRE had them first :-). |
490 |
|
|
491 |
|
16. Related to 15 above: Perl does not treat the | in a conditional group as |
492 |
|
creating alternatives. Such a group is treated in the same way as an |
493 |
|
ordinary group without any | characters when processing (*THEN). PCRE has |
494 |
|
been changed to match Perl's behaviour. |
495 |
|
|
496 |
|
17. If a user had set PCREGREP_COLO(U)R to something other than 1:31, the |
497 |
|
RunGrepTest script failed. |
498 |
|
|
499 |
|
18. Change 22 for version 13 caused atomic groups to use more stack. This is |
500 |
|
inevitable for groups that contain captures, but it can lead to a lot of |
501 |
|
stack use in large patterns. The old behaviour has been restored for atomic |
502 |
|
groups that do not contain any capturing parentheses. |
503 |
|
|
504 |
|
19. If the PCRE_NO_START_OPTIMIZE option was set for pcre_compile(), it did not |
505 |
|
suppress the check for a minimum subject length at run time. (If it was |
506 |
|
given to pcre_exec() or pcre_dfa_exec() it did work.) |
507 |
|
|
508 |
|
20. Fixed an ASCII-dependent infelicity in pcretest that would have made it |
509 |
|
fail to work when decoding hex characters in data strings in EBCDIC |
510 |
|
environments. |
511 |
|
|
512 |
|
21. It appears that in at least one Mac OS environment, the isxdigit() function |
513 |
|
is implemented as a macro that evaluates to its argument more than once, |
514 |
|
contravening the C 90 Standard (I haven't checked a later standard). There |
515 |
|
was an instance in pcretest which caused it to go wrong when processing |
516 |
|
\x{...} escapes in subject strings. The has been rewritten to avoid using |
517 |
|
things like p++ in the argument of isxdigit(). |
518 |
|
|
519 |
|
|
520 |
|
Version 8.13 16-Aug-2011 |
521 |
|
------------------------ |
522 |
|
|
523 |
|
1. The Unicode data tables have been updated to Unicode 6.0.0. |
524 |
|
|
525 |
|
2. Two minor typos in pcre_internal.h have been fixed. |
526 |
|
|
527 |
|
3. Added #include <string.h> to pcre_scanner_unittest.cc, pcrecpp.cc, and |
528 |
|
pcrecpp_unittest.cc. They are needed for strcmp(), memset(), and strchr() |
529 |
|
in some environments (e.g. Solaris 10/SPARC using Sun Studio 12U2). |
530 |
|
|
531 |
|
4. There were a number of related bugs in the code for matching backrefences |
532 |
|
caselessly in UTF-8 mode when codes for the characters concerned were |
533 |
|
different numbers of bytes. For example, U+023A and U+2C65 are an upper |
534 |
|
and lower case pair, using 2 and 3 bytes, respectively. The main bugs were: |
535 |
|
(a) A reference to 3 copies of a 2-byte code matched only 2 of a 3-byte |
536 |
|
code. (b) A reference to 2 copies of a 3-byte code would not match 2 of a |
537 |
|
2-byte code at the end of the subject (it thought there wasn't enough data |
538 |
|
left). |
539 |
|
|
540 |
|
5. Comprehensive information about what went wrong is now returned by |
541 |
|
pcre_exec() and pcre_dfa_exec() when the UTF-8 string check fails, as long |
542 |
|
as the output vector has at least 2 elements. The offset of the start of |
543 |
|
the failing character and a reason code are placed in the vector. |
544 |
|
|
545 |
|
6. When the UTF-8 string check fails for pcre_compile(), the offset that is |
546 |
|
now returned is for the first byte of the failing character, instead of the |
547 |
|
last byte inspected. This is an incompatible change, but I hope it is small |
548 |
|
enough not to be a problem. It makes the returned offset consistent with |
549 |
|
pcre_exec() and pcre_dfa_exec(). |
550 |
|
|
551 |
|
7. pcretest now gives a text phrase as well as the error number when |
552 |
|
pcre_exec() or pcre_dfa_exec() fails; if the error is a UTF-8 check |
553 |
|
failure, the offset and reason code are output. |
554 |
|
|
555 |
|
8. When \R was used with a maximizing quantifier it failed to skip backwards |
556 |
|
over a \r\n pair if the subsequent match failed. Instead, it just skipped |
557 |
|
back over a single character (\n). This seems wrong (because it treated the |
558 |
|
two characters as a single entity when going forwards), conflicts with the |
559 |
|
documentation that \R is equivalent to (?>\r\n|\n|...etc), and makes the |
560 |
|
behaviour of \R* different to (\R)*, which also seems wrong. The behaviour |
561 |
|
has been changed. |
562 |
|
|
563 |
|
9. Some internal refactoring has changed the processing so that the handling |
564 |
|
of the PCRE_CASELESS and PCRE_MULTILINE options is done entirely at compile |
565 |
|
time (the PCRE_DOTALL option was changed this way some time ago: version |
566 |
|
7.7 change 16). This has made it possible to abolish the OP_OPT op code, |
567 |
|
which was always a bit of a fudge. It also means that there is one less |
568 |
|
argument for the match() function, which reduces its stack requirements |
569 |
|
slightly. This change also fixes an incompatibility with Perl: the pattern |
570 |
|
(?i:([^b]))(?1) should not match "ab", but previously PCRE gave a match. |
571 |
|
|
572 |
|
10. More internal refactoring has drastically reduced the number of recursive |
573 |
|
calls to match() for possessively repeated groups such as (abc)++ when |
574 |
|
using pcre_exec(). |
575 |
|
|
576 |
|
11. While implementing 10, a number of bugs in the handling of groups were |
577 |
|
discovered and fixed: |
578 |
|
|
579 |
|
(?<=(a)+) was not diagnosed as invalid (non-fixed-length lookbehind). |
580 |
|
(a|)*(?1) gave a compile-time internal error. |
581 |
|
((a|)+)+ did not notice that the outer group could match an empty string. |
582 |
|
(^a|^)+ was not marked as anchored. |
583 |
|
(.*a|.*)+ was not marked as matching at start or after a newline. |
584 |
|
|
585 |
|
12. Yet more internal refactoring has removed another argument from the match() |
586 |
|
function. Special calls to this function are now indicated by setting a |
587 |
|
value in a variable in the "match data" data block. |
588 |
|
|
589 |
|
13. Be more explicit in pcre_study() instead of relying on "default" for |
590 |
|
opcodes that mean there is no starting character; this means that when new |
591 |
|
ones are added and accidentally left out of pcre_study(), testing should |
592 |
|
pick them up. |
593 |
|
|
594 |
|
14. The -s option of pcretest has been documented for ages as being an old |
595 |
|
synonym of -m (show memory usage). I have changed it to mean "force study |
596 |
|
for every regex", that is, assume /S for every regex. This is similar to -i |
597 |
|
and -d etc. It's slightly incompatible, but I'm hoping nobody is still |
598 |
|
using it. It makes it easier to run collections of tests with and without |
599 |
|
study enabled, and thereby test pcre_study() more easily. All the standard |
600 |
|
tests are now run with and without -s (but some patterns can be marked as |
601 |
|
"never study" - see 20 below). |
602 |
|
|
603 |
|
15. When (*ACCEPT) was used in a subpattern that was called recursively, the |
604 |
|
restoration of the capturing data to the outer values was not happening |
605 |
|
correctly. |
606 |
|
|
607 |
|
16. If a recursively called subpattern ended with (*ACCEPT) and matched an |
608 |
|
empty string, and PCRE_NOTEMPTY was set, pcre_exec() thought the whole |
609 |
|
pattern had matched an empty string, and so incorrectly returned a no |
610 |
|
match. |
611 |
|
|
612 |
|
17. There was optimizing code for the last branch of non-capturing parentheses, |
613 |
|
and also for the obeyed branch of a conditional subexpression, which used |
614 |
|
tail recursion to cut down on stack usage. Unfortunately, now that there is |
615 |
|
the possibility of (*THEN) occurring in these branches, tail recursion is |
616 |
|
no longer possible because the return has to be checked for (*THEN). These |
617 |
|
two optimizations have therefore been removed. [But see 8.20/11 above.] |
618 |
|
|
619 |
|
18. If a pattern containing \R was studied, it was assumed that \R always |
620 |
|
matched two bytes, thus causing the minimum subject length to be |
621 |
|
incorrectly computed because \R can also match just one byte. |
622 |
|
|
623 |
|
19. If a pattern containing (*ACCEPT) was studied, the minimum subject length |
624 |
|
was incorrectly computed. |
625 |
|
|
626 |
|
20. If /S is present twice on a test pattern in pcretest input, it now |
627 |
|
*disables* studying, thereby overriding the use of -s on the command line |
628 |
|
(see 14 above). This is necessary for one or two tests to keep the output |
629 |
|
identical in both cases. |
630 |
|
|
631 |
|
21. When (*ACCEPT) was used in an assertion that matched an empty string and |
632 |
|
PCRE_NOTEMPTY was set, PCRE applied the non-empty test to the assertion. |
633 |
|
|
634 |
|
22. When an atomic group that contained a capturing parenthesis was |
635 |
|
successfully matched, but the branch in which it appeared failed, the |
636 |
|
capturing was not being forgotten if a higher numbered group was later |
637 |
|
captured. For example, /(?>(a))b|(a)c/ when matching "ac" set capturing |
638 |
|
group 1 to "a", when in fact it should be unset. This applied to multi- |
639 |
|
branched capturing and non-capturing groups, repeated or not, and also to |
640 |
|
positive assertions (capturing in negative assertions does not happen |
641 |
|
in PCRE) and also to nested atomic groups. |
642 |
|
|
643 |
|
23. Add the ++ qualifier feature to pcretest, to show the remainder of the |
644 |
|
subject after a captured substring, to make it easier to tell which of a |
645 |
|
number of identical substrings has been captured. |
646 |
|
|
647 |
|
24. The way atomic groups are processed by pcre_exec() has been changed so that |
648 |
|
if they are repeated, backtracking one repetition now resets captured |
649 |
|
values correctly. For example, if ((?>(a+)b)+aabab) is matched against |
650 |
|
"aaaabaaabaabab" the value of captured group 2 is now correctly recorded as |
651 |
|
"aaa". Previously, it would have been "a". As part of this code |
652 |
|
refactoring, the way recursive calls are handled has also been changed. |
653 |
|
|
654 |
|
25. If an assertion condition captured any substrings, they were not passed |
655 |
|
back unless some other capturing happened later. For example, if |
656 |
|
(?(?=(a))a) was matched against "a", no capturing was returned. |
657 |
|
|
658 |
|
26. When studying a pattern that contained subroutine calls or assertions, |
659 |
|
the code for finding the minimum length of a possible match was handling |
660 |
|
direct recursions such as (xxx(?1)|yyy) but not mutual recursions (where |
661 |
|
group 1 called group 2 while simultaneously a separate group 2 called group |
662 |
|
1). A stack overflow occurred in this case. I have fixed this by limiting |
663 |
|
the recursion depth to 10. |
664 |
|
|
665 |
|
27. Updated RunTest.bat in the distribution to the version supplied by Tom |
666 |
|
Fortmann. This supports explicit test numbers on the command line, and has |
667 |
|
argument validation and error reporting. |
668 |
|
|
669 |
|
28. An instance of \X with an unlimited repeat could fail if at any point the |
670 |
|
first character it looked at was a mark character. |
671 |
|
|
672 |
|
29. Some minor code refactoring concerning Unicode properties and scripts |
673 |
|
should reduce the stack requirement of match() slightly. |
674 |
|
|
675 |
|
30. Added the '=' option to pcretest to check the setting of unused capturing |
676 |
|
slots at the end of the pattern, which are documented as being -1, but are |
677 |
|
not included in the return count. |
678 |
|
|
679 |
|
31. If \k was not followed by a braced, angle-bracketed, or quoted name, PCRE |
680 |
|
compiled something random. Now it gives a compile-time error (as does |
681 |
|
Perl). |
682 |
|
|
683 |
|
32. A *MARK encountered during the processing of a positive assertion is now |
684 |
|
recorded and passed back (compatible with Perl). |
685 |
|
|
686 |
|
33. If --only-matching or --colour was set on a pcregrep call whose pattern |
687 |
|
had alternative anchored branches, the search for a second match in a line |
688 |
|
was done as if at the line start. Thus, for example, /^01|^02/ incorrectly |
689 |
|
matched the line "0102" twice. The same bug affected patterns that started |
690 |
|
with a backwards assertion. For example /\b01|\b02/ also matched "0102" |
691 |
|
twice. |
692 |
|
|
693 |
|
34. Previously, PCRE did not allow quantification of assertions. However, Perl |
694 |
|
does, and because of capturing effects, quantifying parenthesized |
695 |
|
assertions may at times be useful. Quantifiers are now allowed for |
696 |
|
parenthesized assertions. |
697 |
|
|
698 |
|
35. A minor code tidy in pcre_compile() when checking options for \R usage. |
699 |
|
|
700 |
|
36. \g was being checked for fancy things in a character class, when it should |
701 |
|
just be a literal "g". |
702 |
|
|
703 |
|
37. PCRE was rejecting [:a[:digit:]] whereas Perl was not. It seems that the |
704 |
|
appearance of a nested POSIX class supersedes an apparent external class. |
705 |
|
For example, [:a[:digit:]b:] matches "a", "b", ":", or a digit. Also, |
706 |
|
unescaped square brackets may also appear as part of class names. For |
707 |
|
example, [:a[:abc]b:] gives unknown class "[:abc]b:]". PCRE now behaves |
708 |
|
more like Perl. (But see 8.20/1 above.) |
709 |
|
|
710 |
|
38. PCRE was giving an error for \N with a braced quantifier such as {1,} (this |
711 |
|
was because it thought it was \N{name}, which is not supported). |
712 |
|
|
713 |
|
39. Add minix to OS list not supporting the -S option in pcretest. |
714 |
|
|
715 |
|
40. PCRE tries to detect cases of infinite recursion at compile time, but it |
716 |
|
cannot analyze patterns in sufficient detail to catch mutual recursions |
717 |
|
such as ((?1))((?2)). There is now a runtime test that gives an error if a |
718 |
|
subgroup is called recursively as a subpattern for a second time at the |
719 |
|
same position in the subject string. In previous releases this might have |
720 |
|
been caught by the recursion limit, or it might have run out of stack. |
721 |
|
|
722 |
|
41. A pattern such as /(?(R)a+|(?R)b)/ is quite safe, as the recursion can |
723 |
|
happen only once. PCRE was, however incorrectly giving a compile time error |
724 |
|
"recursive call could loop indefinitely" because it cannot analyze the |
725 |
|
pattern in sufficient detail. The compile time test no longer happens when |
726 |
|
PCRE is compiling a conditional subpattern, but actual runaway loops are |
727 |
|
now caught at runtime (see 40 above). |
728 |
|
|
729 |
|
42. It seems that Perl allows any characters other than a closing parenthesis |
730 |
|
to be part of the NAME in (*MARK:NAME) and other backtracking verbs. PCRE |
731 |
|
has been changed to be the same. |
732 |
|
|
733 |
|
43. Updated configure.ac to put in more quoting round AC_LANG_PROGRAM etc. so |
734 |
|
as not to get warnings when autogen.sh is called. Also changed |
735 |
|
AC_PROG_LIBTOOL (deprecated) to LT_INIT (the current macro). |
736 |
|
|
737 |
|
44. To help people who use pcregrep to scan files containing exceedingly long |
738 |
|
lines, the following changes have been made: |
739 |
|
|
740 |
|
(a) The default value of the buffer size parameter has been increased from |
741 |
|
8K to 20K. (The actual buffer used is three times this size.) |
742 |
|
|
743 |
|
(b) The default can be changed by ./configure --with-pcregrep-bufsize when |
744 |
|
PCRE is built. |
745 |
|
|
746 |
|
(c) A --buffer-size=n option has been added to pcregrep, to allow the size |
747 |
|
to be set at run time. |
748 |
|
|
749 |
|
(d) Numerical values in pcregrep options can be followed by K or M, for |
750 |
|
example --buffer-size=50K. |
751 |
|
|
752 |
|
(e) If a line being scanned overflows pcregrep's buffer, an error is now |
753 |
|
given and the return code is set to 2. |
754 |
|
|
755 |
|
45. Add a pointer to the latest mark to the callout data block. |
756 |
|
|
757 |
|
46. The pattern /.(*F)/, when applied to "abc" with PCRE_PARTIAL_HARD, gave a |
758 |
|
partial match of an empty string instead of no match. This was specific to |
759 |
|
the use of ".". |
760 |
|
|
761 |
|
47. The pattern /f.*/8s, when applied to "for" with PCRE_PARTIAL_HARD, gave a |
762 |
|
complete match instead of a partial match. This bug was dependent on both |
763 |
|
the PCRE_UTF8 and PCRE_DOTALL options being set. |
764 |
|
|
765 |
|
48. For a pattern such as /\babc|\bdef/ pcre_study() was failing to set up the |
766 |
|
starting byte set, because \b was not being ignored. |
767 |
|
|
768 |
|
|
769 |
|
Version 8.12 15-Jan-2011 |
770 |
|
------------------------ |
771 |
|
|
772 |
|
1. Fixed some typos in the markup of the man pages, and wrote a script that |
773 |
|
checks for such things as part of the documentation building process. |
774 |
|
|
775 |
|
2. On a big-endian 64-bit system, pcregrep did not correctly process the |
776 |
|
--match-limit and --recursion-limit options (added for 8.11). In |
777 |
|
particular, this made one of the standard tests fail. (The integer value |
778 |
|
went into the wrong half of a long int.) |
779 |
|
|
780 |
|
3. If the --colour option was given to pcregrep with -v (invert match), it |
781 |
|
did strange things, either producing crazy output, or crashing. It should, |
782 |
|
of course, ignore a request for colour when reporting lines that do not |
783 |
|
match. |
784 |
|
|
785 |
|
4. Another pcregrep bug caused similar problems if --colour was specified with |
786 |
|
-M (multiline) and the pattern match finished with a line ending. |
787 |
|
|
788 |
|
5. In pcregrep, when a pattern that ended with a literal newline sequence was |
789 |
|
matched in multiline mode, the following line was shown as part of the |
790 |
|
match. This seems wrong, so I have changed it. |
791 |
|
|
792 |
|
6. Another pcregrep bug in multiline mode, when --colour was specified, caused |
793 |
|
the check for further matches in the same line (so they could be coloured) |
794 |
|
to overrun the end of the current line. If another match was found, it was |
795 |
|
incorrectly shown (and then shown again when found in the next line). |
796 |
|
|
797 |
|
7. If pcregrep was compiled under Windows, there was a reference to the |
798 |
|
function pcregrep_exit() before it was defined. I am assuming this was |
799 |
|
the cause of the "error C2371: 'pcregrep_exit' : redefinition;" that was |
800 |
|
reported by a user. I've moved the definition above the reference. |
801 |
|
|
802 |
|
|
803 |
|
Version 8.11 10-Dec-2010 |
804 |
------------------------ |
------------------------ |
805 |
|
|
806 |
1. (*THEN) was not working properly if there were untried alternatives prior |
1. (*THEN) was not working properly if there were untried alternatives prior |
807 |
to it in the current branch. For example, in ((a|b)(*THEN)(*F)|c..) it |
to it in the current branch. For example, in ((a|b)(*THEN)(*F)|c..) it |
808 |
backtracked to try for "b" instead of moving to the next alternative branch |
backtracked to try for "b" instead of moving to the next alternative branch |
809 |
at the same level (in this case, to look for "c"). The Perl documentation |
at the same level (in this case, to look for "c"). The Perl documentation |
810 |
is clear that when (*THEN) is backtracked onto, it goes to the "next |
is clear that when (*THEN) is backtracked onto, it goes to the "next |
811 |
alternative in the innermost enclosing group". |
alternative in the innermost enclosing group". |
812 |
|
|
813 |
2. (*COMMIT) was not overriding (*THEN), as it does in Perl. In a pattern |
2. (*COMMIT) was not overriding (*THEN), as it does in Perl. In a pattern |
814 |
such as (A(*COMMIT)B(*THEN)C|D) any failure after matching A should |
such as (A(*COMMIT)B(*THEN)C|D) any failure after matching A should |
815 |
result in overall failure. Similarly, (*COMMIT) now overrides (*PRUNE) and |
result in overall failure. Similarly, (*COMMIT) now overrides (*PRUNE) and |
816 |
(*SKIP), (*SKIP) overrides (*PRUNE) and (*THEN), and (*PRUNE) overrides |
(*SKIP), (*SKIP) overrides (*PRUNE) and (*THEN), and (*PRUNE) overrides |
817 |
(*THEN). |
(*THEN). |
818 |
|
|
819 |
3. If \s appeared in a character class, it removed the VT character from |
3. If \s appeared in a character class, it removed the VT character from |
820 |
the class, even if it had been included by some previous item, for example |
the class, even if it had been included by some previous item, for example |
821 |
in [\x00-\xff\s]. (This was a bug related to the fact that VT is not part |
in [\x00-\xff\s]. (This was a bug related to the fact that VT is not part |
822 |
of \s, but is part of the POSIX "space" class.) |
of \s, but is part of the POSIX "space" class.) |
823 |
|
|
824 |
4. A partial match never returns an empty string (because you can always |
4. A partial match never returns an empty string (because you can always |
825 |
match an empty string at the end of the subject); however the checking for |
match an empty string at the end of the subject); however the checking for |
826 |
an empty string was starting at the "start of match" point. This has been |
an empty string was starting at the "start of match" point. This has been |
830 |
(previously it gave "no match"). |
(previously it gave "no match"). |
831 |
|
|
832 |
5. Changes have been made to the way PCRE_PARTIAL_HARD affects the matching |
5. Changes have been made to the way PCRE_PARTIAL_HARD affects the matching |
833 |
of $, \z, \Z, \b, and \B. If the match point is at the end of the string, |
of $, \z, \Z, \b, and \B. If the match point is at the end of the string, |
834 |
previously a full match would be given. However, setting PCRE_PARTIAL_HARD |
previously a full match would be given. However, setting PCRE_PARTIAL_HARD |
835 |
has an implication that the given string is incomplete (because a partial |
has an implication that the given string is incomplete (because a partial |
836 |
match is preferred over a full match). For this reason, these items now |
match is preferred over a full match). For this reason, these items now |
837 |
give a partial match in this situation. [Aside: previously, the one case |
give a partial match in this situation. [Aside: previously, the one case |
838 |
/t\b/ matched against "cat" with PCRE_PARTIAL_HARD set did return a partial |
/t\b/ matched against "cat" with PCRE_PARTIAL_HARD set did return a partial |
839 |
match rather than a full match, which was wrong by the old rules, but is |
match rather than a full match, which was wrong by the old rules, but is |
840 |
now correct.] |
now correct.] |
841 |
|
|
842 |
6. There was a bug in the handling of #-introduced comments, recognized when |
6. There was a bug in the handling of #-introduced comments, recognized when |
843 |
PCRE_EXTENDED is set, when PCRE_NEWLINE_ANY and PCRE_UTF8 were also set. |
PCRE_EXTENDED is set, when PCRE_NEWLINE_ANY and PCRE_UTF8 were also set. |
844 |
If a UTF-8 multi-byte character included the byte 0x85 (e.g. +U0445, whose |
If a UTF-8 multi-byte character included the byte 0x85 (e.g. +U0445, whose |
845 |
UTF-8 encoding is 0xd1,0x85), this was misinterpreted as a newline when |
UTF-8 encoding is 0xd1,0x85), this was misinterpreted as a newline when |
846 |
scanning for the end of the comment. (*Character* 0x85 is an "any" newline, |
scanning for the end of the comment. (*Character* 0x85 is an "any" newline, |
847 |
but *byte* 0x85 is not, in UTF-8 mode). This bug was present in several |
but *byte* 0x85 is not, in UTF-8 mode). This bug was present in several |
848 |
places in pcre_compile(). |
places in pcre_compile(). |
849 |
|
|
850 |
7. Related to (6) above, when pcre_compile() was skipping #-introduced |
7. Related to (6) above, when pcre_compile() was skipping #-introduced |
851 |
comments when looking ahead for named forward references to subpatterns, |
comments when looking ahead for named forward references to subpatterns, |
852 |
the only newline sequence it recognized was NL. It now handles newlines |
the only newline sequence it recognized was NL. It now handles newlines |
853 |
according to the set newline convention. |
according to the set newline convention. |
854 |
|
|
855 |
8. SunOS4 doesn't have strerror() or strtoul(); pcregrep dealt with the |
8. SunOS4 doesn't have strerror() or strtoul(); pcregrep dealt with the |
856 |
former, but used strtoul(), whereas pcretest avoided strtoul() but did not |
former, but used strtoul(), whereas pcretest avoided strtoul() but did not |
857 |
cater for a lack of strerror(). These oversights have been fixed. |
cater for a lack of strerror(). These oversights have been fixed. |
858 |
|
|
859 |
9. Added --match-limit and --recursion-limit to pcregrep. |
9. Added --match-limit and --recursion-limit to pcregrep. |
860 |
|
|
861 |
10. Added two casts needed to build with Visual Studio when NO_RECURSE is set. |
10. Added two casts needed to build with Visual Studio when NO_RECURSE is set. |
862 |
|
|
863 |
11. When the -o option was used, pcregrep was setting a return code of 1, even |
11. When the -o option was used, pcregrep was setting a return code of 1, even |
864 |
when matches were found, and --line-buffered was not being honoured. |
when matches were found, and --line-buffered was not being honoured. |
865 |
|
|
866 |
12. Added an optional parentheses number to the -o and --only-matching options |
12. Added an optional parentheses number to the -o and --only-matching options |
867 |
of pcregrep. |
of pcregrep. |
868 |
|
|
869 |
|
13. Imitating Perl's /g action for multiple matches is tricky when the pattern |
870 |
|
can match an empty string. The code to do it in pcretest and pcredemo |
871 |
|
needed fixing: |
872 |
|
|
873 |
|
(a) When the newline convention was "crlf", pcretest got it wrong, skipping |
874 |
|
only one byte after an empty string match just before CRLF (this case |
875 |
|
just got forgotten; "any" and "anycrlf" were OK). |
876 |
|
|
877 |
|
(b) The pcretest code also had a bug, causing it to loop forever in UTF-8 |
878 |
|
mode when an empty string match preceded an ASCII character followed by |
879 |
|
a non-ASCII character. (The code for advancing by one character rather |
880 |
|
than one byte was nonsense.) |
881 |
|
|
882 |
|
(c) The pcredemo.c sample program did not have any code at all to handle |
883 |
|
the cases when CRLF is a valid newline sequence. |
884 |
|
|
885 |
|
14. Neither pcre_exec() nor pcre_dfa_exec() was checking that the value given |
886 |
|
as a starting offset was within the subject string. There is now a new |
887 |
|
error, PCRE_ERROR_BADOFFSET, which is returned if the starting offset is |
888 |
|
negative or greater than the length of the string. In order to test this, |
889 |
|
pcretest is extended to allow the setting of negative starting offsets. |
890 |
|
|
891 |
|
15. In both pcre_exec() and pcre_dfa_exec() the code for checking that the |
892 |
|
starting offset points to the beginning of a UTF-8 character was |
893 |
|
unnecessarily clumsy. I tidied it up. |
894 |
|
|
895 |
|
16. Added PCRE_ERROR_SHORTUTF8 to make it possible to distinguish between a |
896 |
|
bad UTF-8 sequence and one that is incomplete when using PCRE_PARTIAL_HARD. |
897 |
|
|
898 |
|
17. Nobody had reported that the --include_dir option, which was added in |
899 |
|
release 7.7 should have been called --include-dir (hyphen, not underscore) |
900 |
|
for compatibility with GNU grep. I have changed it to --include-dir, but |
901 |
|
left --include_dir as an undocumented synonym, and the same for |
902 |
|
--exclude-dir, though that is not available in GNU grep, at least as of |
903 |
|
release 2.5.4. |
904 |
|
|
905 |
|
18. At a user's suggestion, the macros GETCHAR and friends (which pick up UTF-8 |
906 |
|
characters from a string of bytes) have been redefined so as not to use |
907 |
|
loops, in order to improve performance in some environments. At the same |
908 |
|
time, I abstracted some of the common code into auxiliary macros to save |
909 |
|
repetition (this should not affect the compiled code). |
910 |
|
|
911 |
|
19. If \c was followed by a multibyte UTF-8 character, bad things happened. A |
912 |
|
compile-time error is now given if \c is not followed by an ASCII |
913 |
|
character, that is, a byte less than 128. (In EBCDIC mode, the code is |
914 |
|
different, and any byte value is allowed.) |
915 |
|
|
916 |
|
20. Recognize (*NO_START_OPT) at the start of a pattern to set the PCRE_NO_ |
917 |
|
START_OPTIMIZE option, which is now allowed at compile time - but just |
918 |
|
passed through to pcre_exec() or pcre_dfa_exec(). This makes it available |
919 |
|
to pcregrep and other applications that have no direct access to PCRE |
920 |
|
options. The new /Y option in pcretest sets this option when calling |
921 |
|
pcre_compile(). |
922 |
|
|
923 |
|
21. Change 18 of release 8.01 broke the use of named subpatterns for recursive |
924 |
|
back references. Groups containing recursive back references were forced to |
925 |
|
be atomic by that change, but in the case of named groups, the amount of |
926 |
|
memory required was incorrectly computed, leading to "Failed: internal |
927 |
|
error: code overflow". This has been fixed. |
928 |
|
|
929 |
|
22. Some patches to pcre_stringpiece.h, pcre_stringpiece_unittest.cc, and |
930 |
|
pcretest.c, to avoid build problems in some Borland environments. |
931 |
|
|
932 |
|
|
933 |
Version 8.10 25-Jun-2010 |
Version 8.10 25-Jun-2010 |