| 38 |
counting zeros. There was no check for running off the end of the string, |
counting zeros. There was no check for running off the end of the string, |
| 39 |
which could happen if a new error number was added without updating the |
which could happen if a new error number was added without updating the |
| 40 |
string. |
string. |
| 41 |
|
|
| 42 |
|
10. \K gave a compile-time error if it appeared in a lookbehind assersion. |
| 43 |
|
|
| 44 |
|
11. \K was not working if it appeared in an atomic group or in a group that |
| 45 |
|
was called as a "subroutine", or in an assertion. Perl 5.11 documents that |
| 46 |
|
\K is "not well defined" if used in an assertion. PCRE now accepts it if |
| 47 |
|
the assertion is positive, but not if it is negative. |
| 48 |
|
|
| 49 |
|
12. Change 11 fortuitously reduced the size of the stack frame used in the |
| 50 |
|
"match()" function of pcre_exec.c by one pointer. Forthcoming |
| 51 |
|
implementation of support for (*MARK) will need an extra pointer on the |
| 52 |
|
stack; I have reserved it now, so that the stack frame size does not |
| 53 |
|
decrease. |
| 54 |
|
|
| 55 |
|
13. A pattern such as (?P<L1>(?P<L2>0)|(?P>L2)(?P>L1)) in which the only other |
| 56 |
|
item in branch that calls a recursion is a subroutine call - as in the |
| 57 |
|
second branch in the above example - was incorrectly given the compile- |
| 58 |
|
time error "recursive call could loop indefinitely" because pcre_compile() |
| 59 |
|
was not correctly checking the subroutine for matching a non-empty string. |
| 60 |
|
|
| 61 |
|
14. The checks for overrunning compiling workspace could trigger after an |
| 62 |
|
overrun had occurred. This is a "should never occur" error, but it can be |
| 63 |
|
triggered by pathological patterns such as hundreds of nested parentheses. |
| 64 |
|
The checks now trigger 100 bytes before the end of the workspace. |
| 65 |
|
|
| 66 |
|
|
| 67 |
Version 8.01 19-Jan-2010 |
Version 8.01 19-Jan-2010 |
Parent Directory
| 
Revision Log
| 
Patch