| 150 |
|
|
| 151 |
27. Patterns such as (\P{Yi}*\277)* (group with possible zero repeat containing |
27. Patterns such as (\P{Yi}*\277)* (group with possible zero repeat containing |
| 152 |
\p or \P) caused a compile-time loop. |
\p or \P) caused a compile-time loop. |
| 153 |
|
|
| 154 |
|
28. More problems have arisen in unanchored patterns when CRLF is a valid line |
| 155 |
|
break. For example, the unstudied pattern [\r\n]A does not match the string |
| 156 |
|
"\r\nA" because change 7.0/46 below moves the current point on by two |
| 157 |
|
characters after failing to match at the start. However, the pattern \nA |
| 158 |
|
*does* match, because it doesn't start till \n, and if [\r\n]A is studied, |
| 159 |
|
the same is true. There doesn't seem any very clean way out of this, but |
| 160 |
|
what I have chosen to do makes the common cases work: PCRE now takes note |
| 161 |
|
of whether there can be an explicit match for \r or \n anywhere in the |
| 162 |
|
pattern, and if so, 7.0/46 no longer applies. As part of this change, |
| 163 |
|
there's a new PCRE_INFO_HASCRORLF option for finding out whether a compiled |
| 164 |
|
pattern has explicit CR or LF references. |
| 165 |
|
|
| 166 |
|
|
| 167 |
Version 7.2 19-Jun-07 |
Version 7.2 19-Jun-07 |
Parent Directory
| 
Revision Log
| 
Patch