116 |
|
|
117 |
20. Debugging a pattern containing \p or \P could cause a crash. For example, |
20. Debugging a pattern containing \p or \P could cause a crash. For example, |
118 |
[\P{Any}] did so. (Error in the code for printing property names.) |
[\P{Any}] did so. (Error in the code for printing property names.) |
119 |
|
|
120 |
|
21. An orphan \E inside a character class could cause a crash. |
121 |
|
|
122 |
|
22. A repeated capturing bracket such as (A)? could cause a wild memory |
123 |
|
reference during compilation. |
124 |
|
|
125 |
|
23. There are several functions in pcre_compile() that scan along a compiled |
126 |
|
expression for various reasons (e.g. to see if it's fixed length for look |
127 |
|
behind). There were bugs in these functions when a repeated \p or \P was |
128 |
|
present in the pattern. These operators have additional parameters compared |
129 |
|
with \d, etc, and these were not being taken into account when moving along |
130 |
|
the compiled data. Specifically: |
131 |
|
|
132 |
|
(a) A item such as \p{Yi}{3} in a lookbehind was not treated as fixed |
133 |
|
length. |
134 |
|
|
135 |
|
(b) An item such as \pL+ within a repeated group could cause crashes or |
136 |
|
loops. |
137 |
|
|
138 |
|
(c) A pattern such as \p{Yi}+(\P{Yi}+)(?1) could give an incorrect |
139 |
|
"reference to non-existent subpattern" error. |
140 |
|
|
141 |
|
|
142 |
Version 7.2 19-Jun-07 |
Version 7.2 19-Jun-07 |