| 165 |
|
|
| 166 |
31. A *MARK encountered during the processing of a positive assertion is now |
31. A *MARK encountered during the processing of a positive assertion is now |
| 167 |
recorded and passed back (compatible with Perl). |
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 |
|
|
| 213 |
Version 8.12 15-Jan-2011 |
Version 8.12 15-Jan-2011 |
Parent Directory
| 
Revision Log
| 
Patch