| 1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
| 2 |
------------------ |
------------------ |
| 3 |
|
|
| 4 |
Version 7.3 17-Aug-07 |
Version 7.4 10-Sep-07 |
| 5 |
|
--------------------- |
| 6 |
|
|
| 7 |
|
1. Change 7.3/28 was implemented for classes by looking at the bitmap. This |
| 8 |
|
means that a class such as [\s] counted as "explicit reference to CR or |
| 9 |
|
LF". That isn't really right - the whole point of the change was to try to |
| 10 |
|
help when there was an actual mention of one of the two characters. So now |
| 11 |
|
the change happens only if \r or \n (or a literal CR or LF) character is |
| 12 |
|
encountered. |
| 13 |
|
|
| 14 |
|
2. The 32-bit options word was also used for 6 internal flags, but the numbers |
| 15 |
|
of both had grown to the point where there were only 3 bits left. |
| 16 |
|
Fortunately, there was spare space in the data structure, and so I have |
| 17 |
|
moved the internal flags into a new 16-bit field to free up more option |
| 18 |
|
bits. |
| 19 |
|
|
| 20 |
|
3. The appearance of (?J) at the start of a pattern set the DUPNAMES option, |
| 21 |
|
but did not set the internal JCHANGED flag - either of these is enough to |
| 22 |
|
control the way the "get" function works - but the PCRE_INFO_JCHANGED |
| 23 |
|
facility is supposed to tell if (?J) was ever used, so now (?J) at the |
| 24 |
|
start sets both bits. |
| 25 |
|
|
| 26 |
|
4. Added options (at build time, compile time, exec time) to change \R from |
| 27 |
|
matching any Unicode line ending sequence to just matching CR, LF, or CRLF. |
| 28 |
|
|
| 29 |
|
5. doc/pcresyntax.html was missing from the distribution. |
| 30 |
|
|
| 31 |
|
|
| 32 |
|
Version 7.3 28-Aug-07 |
| 33 |
--------------------- |
--------------------- |
| 34 |
|
|
| 35 |
1. In the rejigging of the build system that eventually resulted in 7.1, the |
1. In the rejigging of the build system that eventually resulted in 7.1, the |
| 171 |
24. A repeated \S or \W in UTF-8 mode could give wrong answers when multibyte |
24. A repeated \S or \W in UTF-8 mode could give wrong answers when multibyte |
| 172 |
characters were involved (for example /\S{2}/8g with "A\x{a3}BC"). |
characters were involved (for example /\S{2}/8g with "A\x{a3}BC"). |
| 173 |
|
|
| 174 |
|
25. Using pcregrep in multiline, inverted mode (-Mv) caused it to loop. |
| 175 |
|
|
| 176 |
|
26. Patterns such as [\P{Yi}A] which include \p or \P and just one other |
| 177 |
|
character were causing crashes (broken optimization). |
| 178 |
|
|
| 179 |
|
27. Patterns such as (\P{Yi}*\277)* (group with possible zero repeat containing |
| 180 |
|
\p or \P) caused a compile-time loop. |
| 181 |
|
|
| 182 |
|
28. More problems have arisen in unanchored patterns when CRLF is a valid line |
| 183 |
|
break. For example, the unstudied pattern [\r\n]A does not match the string |
| 184 |
|
"\r\nA" because change 7.0/46 below moves the current point on by two |
| 185 |
|
characters after failing to match at the start. However, the pattern \nA |
| 186 |
|
*does* match, because it doesn't start till \n, and if [\r\n]A is studied, |
| 187 |
|
the same is true. There doesn't seem any very clean way out of this, but |
| 188 |
|
what I have chosen to do makes the common cases work: PCRE now takes note |
| 189 |
|
of whether there can be an explicit match for \r or \n anywhere in the |
| 190 |
|
pattern, and if so, 7.0/46 no longer applies. As part of this change, |
| 191 |
|
there's a new PCRE_INFO_HASCRORLF option for finding out whether a compiled |
| 192 |
|
pattern has explicit CR or LF references. |
| 193 |
|
|
| 194 |
|
29. Added (*CR) etc for changing newline setting at start of pattern. |
| 195 |
|
|
| 196 |
|
|
| 197 |
Version 7.2 19-Jun-07 |
Version 7.2 19-Jun-07 |
| 198 |
--------------------- |
--------------------- |
Parent Directory
| 
Revision Log
| 
Patch