| 36 |
pcre_exec() or pcre_dfa_exec() fails; if the error is a UTF-8 check |
pcre_exec() or pcre_dfa_exec() fails; if the error is a UTF-8 check |
| 37 |
failure, the offset and reason code are output. |
failure, the offset and reason code are output. |
| 38 |
|
|
| 39 |
|
8. When \R was used with a maximizing quantifier it failed to skip backwards |
| 40 |
|
over a \r\n pair if the subsequent match failed. Instead, it just skipped |
| 41 |
|
back over a single character (\n). This seems wrong (because it treated the |
| 42 |
|
two characters as a single entity when going forwards), conflicts with the |
| 43 |
|
documentation that \R is equivalent to (?>\r\n|\n|...etc), and makes the |
| 44 |
|
behaviour of \R* different to (\R)*, which also seems wrong. The behaviour |
| 45 |
|
has been changed. |
| 46 |
|
|
| 47 |
|
9. Some internal refactoring has changed the processing so that the handling |
| 48 |
|
of the PCRE_CASELESS and PCRE_MULTILINE options is done entirely at compile |
| 49 |
|
time (the PCRE_DOTALL option was changed this way some time ago: version |
| 50 |
|
7.7 change 16). This has made it possible to abolish the OP_OPT op code, |
| 51 |
|
which was always a bit of a fudge. It also means that there is one less |
| 52 |
|
argument for the match() function, which reduces its stack requirements |
| 53 |
|
slightly. This change also fixes an incompatibility with Perl: the pattern |
| 54 |
|
(?i:([^b]))(?1) should not match "ab", but previously PCRE gave a match. |
| 55 |
|
|
| 56 |
|
10. More internal refactoring has drastically reduced the number of recursive |
| 57 |
|
calls to match() for possessively repeated groups such as (abc)++ when |
| 58 |
|
using pcre_exec(). |
| 59 |
|
|
| 60 |
|
11. While implementing 10, a number of bugs in the handling of groups were |
| 61 |
|
discovered and fixed: |
| 62 |
|
|
| 63 |
|
(?<=(a)+) was not diagnosed as invalid (non-fixed-length lookbehind). |
| 64 |
|
(a|)*(?1) gave a compile-time internal error. |
| 65 |
|
((a|)+)+ did not notice that the outer group could match an empty string. |
| 66 |
|
(^a|^)+ was not marked as anchored. |
| 67 |
|
(.*a|.*)+ was not marked as matching at start or after a newline. |
| 68 |
|
|
| 69 |
|
12. Yet more internal refactoring has removed another argument from the match() |
| 70 |
|
function. Special calls to this function are now indicated by setting a |
| 71 |
|
value in a variable in the "match data" data block. |
| 72 |
|
|
| 73 |
|
13. Be more explicit in pcre_study() instead of relying on "default" for |
| 74 |
|
opcodes that mean there is no starting character; this means that when new |
| 75 |
|
ones are added and accidentally left out of pcre_study(), testing should |
| 76 |
|
pick them up. |
| 77 |
|
|
| 78 |
|
14. The -s option of pcretest has been documented for ages as being an old |
| 79 |
|
synonym of -m (show memory usage). I have changed it to mean "force study |
| 80 |
|
for every regex", that is, assume /S for every regex. This is similar to -i |
| 81 |
|
and -d etc. It's slightly incompatible, but I'm hoping nobody is still |
| 82 |
|
using it. It makes it easier to run collections of tests with and without |
| 83 |
|
study enabled, and thereby test pcre_study() more easily. All the standard |
| 84 |
|
tests are now run with and without -s (but some patterns can be marked as |
| 85 |
|
"never study" - see 20 below). |
| 86 |
|
|
| 87 |
|
15. When (*ACCEPT) was used in a subpattern that was called recursively, the |
| 88 |
|
restoration of the capturing data to the outer values was not happening |
| 89 |
|
correctly. |
| 90 |
|
|
| 91 |
|
16. If a recursively called subpattern ended with (*ACCEPT) and matched an |
| 92 |
|
empty string, and PCRE_NOTEMPTY was set, pcre_exec() thought the whole |
| 93 |
|
pattern had matched an empty string, and so incorrectly returned a no |
| 94 |
|
match. |
| 95 |
|
|
| 96 |
|
17. There was optimizing code for the last branch of non-capturing parentheses, |
| 97 |
|
and also for the obeyed branch of a conditional subexpression, which used |
| 98 |
|
tail recursion to cut down on stack usage. Unfortunately, not that there is |
| 99 |
|
the possibility of (*THEN) occurring in these branches, tail recursion is |
| 100 |
|
no longer possible because the return has to be checked for (*THEN). These |
| 101 |
|
two optimizations have therefore been removed. |
| 102 |
|
|
| 103 |
|
18. If a pattern containing \R was studied, it was assumed that \R always |
| 104 |
|
matched two bytes, thus causing the minimum subject length to be |
| 105 |
|
incorrectly computed because \R can also match just one byte. |
| 106 |
|
|
| 107 |
|
19. If a pattern containing (*ACCEPT) was studied, the minimum subject length |
| 108 |
|
was incorrectly computed. |
| 109 |
|
|
| 110 |
|
20. If /S is present twice on a test pattern in pcretest input, it *disables* |
| 111 |
|
studying, thereby overriding the use of -s on the command line. This is |
| 112 |
|
necessary for one or two tests to keep the output identical in both cases. |
| 113 |
|
|
| 114 |
|
21. When (*ACCEPT) was used in an assertion that matched an empty string and |
| 115 |
|
PCRE_NOTEMPTY was set, PCRE applied the non-empty test to the assertion. |
| 116 |
|
|
| 117 |
|
22. When an atomic group that contained a capturing parenthesis was |
| 118 |
|
successfully matched, but the branch in which it appeared failed, the |
| 119 |
|
capturing was not being forgotten if a higher numbered group was later |
| 120 |
|
captured. For example, /(?>(a))b|(a)c/ when matching "ac" set capturing |
| 121 |
|
group 1 to "a", when in fact it should be unset. This applied to multi- |
| 122 |
|
branched capturing and non-capturing groups, repeated or not, and also to |
| 123 |
|
positive assertions (capturing in negative assertions is not well defined |
| 124 |
|
in PCRE) and also to nested atomic groups. |
| 125 |
|
|
| 126 |
|
23. Add the ++ qualifier feature to pcretest, to show the remainder of the |
| 127 |
|
subject after a captured substring (to make it easier to tell which of a |
| 128 |
|
number of identical substrings has been captured). |
| 129 |
|
|
| 130 |
|
24. The way atomic groups are processed by pcre_exec() has been changed so that |
| 131 |
|
if they are repeated, backtracking one repetition now resets captured |
| 132 |
|
values correctly. For example, if ((?>(a+)b)+aabab) is matched against |
| 133 |
|
"aaaabaaabaabab" the value of captured group 2 is now correctly recorded as |
| 134 |
|
"aaa". Previously, it would have been "a". As part of this code |
| 135 |
|
refactoring, the way recursive calls are handled has also been changed. |
| 136 |
|
|
| 137 |
|
24. If an assertion condition captured any substrings, they were not passed |
| 138 |
|
back unless some other capturing happened later. For example, if |
| 139 |
|
(?(?=(a))a) was matched against "a", no capturing was returned. |
| 140 |
|
|
| 141 |
|
25. When studying a pattern that contained subroutine calls or assertions, |
| 142 |
|
the code for finding the minimum length of a possible match was handling |
| 143 |
|
direct recursions such as (xxx(?1)|yyy) but not mutual recursions (where |
| 144 |
|
group 1 called group 2 while simultaneously a separate group 2 called group |
| 145 |
|
1). A stack overflow occurred in this case. I have fixed this by limiting |
| 146 |
|
the recursion depth to 10. |
| 147 |
|
|
| 148 |
|
26. Updated RunTest.bat in the distribution to the version supplied by Tom |
| 149 |
|
Fortmann. This supports explicit test numbers on the command line, and has |
| 150 |
|
argument validation and error reporting. |
| 151 |
|
|
| 152 |
|
27. An instance of \X with an unlimited repeat could fail if at any point the |
| 153 |
|
first character it looked at was a mark character. |
| 154 |
|
|
| 155 |
|
28. Some minor code refactoring concerning Unicode properties and scripts |
| 156 |
|
should reduce the stack requirement of match() slightly. |
| 157 |
|
|
| 158 |
|
29. Added the '=' option to pcretest to check the setting of unused capturing |
| 159 |
|
slots at the end of the pattern, which are documented as being -1, but are |
| 160 |
|
not included in the return count. |
| 161 |
|
|
| 162 |
|
30. If \k was not followed by a braced, angle-bracketed, or quoted name, PCRE |
| 163 |
|
compiled something random. Now it gives a compile-time error (as does |
| 164 |
|
Perl). |
| 165 |
|
|
| 166 |
|
31. A *MARK encountered during the processing of a positive assertion is now |
| 167 |
|
recorded and passed back (compatible with Perl). |
| 168 |
|
|
| 169 |
|
32. If --only-matching or --colour was set on a pcregrep call whose pattern |
| 170 |
|
had alternative anchored branches, the search for a second match in a line |
| 171 |
|
was done as if at the line start. Thus, for example, /^01|^02/ incorrectly |
| 172 |
|
matched the line "0102" twice. The same bug affected patterns that started |
| 173 |
|
with a backwards assertion. For example /\b01|\b02/ also matched "0102" |
| 174 |
|
twice. |
| 175 |
|
|
| 176 |
|
33. Previously, PCRE did not allow quantification of assertions. However, Perl |
| 177 |
|
does, and because of capturing effects, quantifying parenthesized |
| 178 |
|
assertions may at times be useful. Quantifiers are now allowed for |
| 179 |
|
parenthesized assertions. |
| 180 |
|
|
| 181 |
|
34. A minor code tidy in pcre_compile() when checking options for \R usage. |
| 182 |
|
|
| 183 |
|
35. \g was being checked for fancy things in a character class, when it should |
| 184 |
|
just be a literal "g". |
| 185 |
|
|
| 186 |
|
36. PCRE was rejecting [:a[:digit:]] whereas Perl was not. It seems that the |
| 187 |
|
appearance of a nested POSIX class supersedes an apparent external class. |
| 188 |
|
For example, [:a[:digit:]b:] matches "a", "b", ":", or a digit. Also, |
| 189 |
|
unescaped square brackets may also appear as part of class names. For |
| 190 |
|
example, [:a[:abc]b:] gives unknown class "[:abc]b:]". PCRE now behaves |
| 191 |
|
more like Perl. |
| 192 |
|
|
| 193 |
|
37. PCRE was giving an error for \N with a braced quantifier such as {1,} (this |
| 194 |
|
was because it thought it was \N{name}, which is not supported). |
| 195 |
|
|
| 196 |
|
38. Add minix to OS list not supporting the -S option in pcretest. |
| 197 |
|
|
| 198 |
|
39. PCRE tries to detect cases of infinite recursion at compile time, but it |
| 199 |
|
cannot analyze patterns in sufficient detail to catch mutual recursions |
| 200 |
|
such as ((?1))((?2)). There is now a runtime test that gives an error if a |
| 201 |
|
subgroup is called recursively as a subpattern for a second time at the |
| 202 |
|
same position in the subject string. In previous releases this might have |
| 203 |
|
been caught by the recursion limit, or it might have run out of stack. |
| 204 |
|
|
| 205 |
|
40. A pattern such as /(?(R)a+|(?R)b)/ is quite safe, as the recursion can |
| 206 |
|
happen only once. PCRE was, however incorrectly giving a compile time error |
| 207 |
|
"recursive call could loop indefinitely" because it cannot analyze the |
| 208 |
|
pattern in sufficient detail. The compile time test no longer happens when |
| 209 |
|
PCRE is compiling a conditional subpattern, but actual runaway loops are |
| 210 |
|
now caught at runtime (see 39 above). |
| 211 |
|
|
| 212 |
|
41. It seems that Perl allows any characters other than a closing parenthesis |
| 213 |
|
to be part of the NAME in (*MARK:NAME) and other backtracking verbs. PCRE |
| 214 |
|
has been changed to be the same. |
| 215 |
|
|
| 216 |
|
42. Updated configure.ac to put in more quoting round AC_LANG_PROGRAM etc. so |
| 217 |
|
as not to get warnings when autogen.sh is called. Also changed |
| 218 |
|
AC_PROG_LIBTOOL (deprecated) to LT_INIT (the current macro). |
| 219 |
|
|
| 220 |
|
43. To help people who use pcregrep to scan files containing exceedingly long |
| 221 |
|
lines, the following changes have been made: |
| 222 |
|
|
| 223 |
|
(a) The default value of the buffer size parameter has been increased from |
| 224 |
|
8K to 20K. (A buffer three times this size is actually used.) |
| 225 |
|
|
| 226 |
|
(b) The default can be changed by ./configure --with-pcregrep-bufsiz when |
| 227 |
|
PCRE is built. |
| 228 |
|
|
| 229 |
|
(c) A --buffer-size=n option has been added to pcregrep, to allow the size |
| 230 |
|
to be set at run time. |
| 231 |
|
|
| 232 |
|
(d) Numerical values in pcregrep options can be followed by K or M, for |
| 233 |
|
example --buffer-size=50K. |
| 234 |
|
|
| 235 |
|
(e) If a line being scanned overflows pcregrep's buffer, an error is now |
| 236 |
|
given and the return code is set to 2. |
| 237 |
|
|
| 238 |
|
44. Add a pointer to the latest mark to the callout data block. |
| 239 |
|
|
| 240 |
|
45. The pattern /.(*F)/, when applied to "abc" with PCRE_PARTIAL_HARD, gave a |
| 241 |
|
partial match of an empty string instead of no match. This was specific to |
| 242 |
|
the use of ".". |
| 243 |
|
|
| 244 |
|
46. The pattern /f.*/8s, when applied to "for" with PCRE_PARTIAL_HARD, gave a |
| 245 |
|
complete match instead of a partial match. This bug was dependent on both |
| 246 |
|
the PCRE_UTF8 and PCRE_DOTALL options being set. |
| 247 |
|
|
| 248 |
|
|
| 249 |
Version 8.12 15-Jan-2011 |
Version 8.12 15-Jan-2011 |
Parent Directory
| 
Revision Log
| 
Patch