| 21 |
5. The construct (?&) was not diagnosed as a syntax error (it referenced the |
5. The construct (?&) was not diagnosed as a syntax error (it referenced the |
| 22 |
first named subpattern) and a construct such as (?&a) would reference the |
first named subpattern) and a construct such as (?&a) would reference the |
| 23 |
first named subpattern whose name started with "a" (in other words, the |
first named subpattern whose name started with "a" (in other words, the |
| 24 |
length check was missing). |
length check was missing). Both these problems are fixed. "Subpattern name |
| 25 |
|
expected" is now given for (?&) (a zero-length name), and this patch also |
| 26 |
|
makes it give the same error for \k'' (previously it complained that that |
| 27 |
|
was a reference to a non-existent subpattern). |
| 28 |
|
|
| 29 |
6. The erroneous patterns (?+-a) and (?-+a) give different error messages; |
6. The erroneous patterns (?+-a) and (?-+a) give different error messages; |
| 30 |
this is right because (?- can be followed by option settings as well as by |
this is right because (?- can be followed by option settings as well as by |
| 35 |
This is actually not compatible with Perl, which accepts such patterns, but |
This is actually not compatible with Perl, which accepts such patterns, but |
| 36 |
treats the conditional as always being FALSE (as PCRE used to), but it |
treats the conditional as always being FALSE (as PCRE used to), but it |
| 37 |
seems to me that giving a diagnostic is better. |
seems to me that giving a diagnostic is better. |
| 38 |
|
|
| 39 |
|
8. Change "alphameric" to the more common word "alphanumeric" in comments |
| 40 |
|
and messages. |
| 41 |
|
|
| 42 |
|
9. Fix two occurrences of "backslash" in comments that should have been |
| 43 |
|
"backspace". |
| 44 |
|
|
| 45 |
|
10. Remove two redundant lines of code that can never be obeyed (their function |
| 46 |
|
was moved elsewhere). |
| 47 |
|
|
| 48 |
|
11. The program that makes PCRE's Unicode character property table had a bug |
| 49 |
|
which caused it to generate incorrect table entries for sequences of |
| 50 |
|
characters that have the same character type, but are in different scripts. |
| 51 |
|
It amalgamated them into a single range, with the script of the first of |
| 52 |
|
them. In other words, some characters were in the wrong script. There were |
| 53 |
|
thirteen such cases, affecting characters in the following ranges: |
| 54 |
|
|
| 55 |
|
U+002b0 - U+002c1 |
| 56 |
|
U+0060c - U+0060d |
| 57 |
|
U+0061e - U+00612 |
| 58 |
|
U+0064b - U+0065e |
| 59 |
|
U+0074d - U+0076d |
| 60 |
|
U+01800 - U+01805 |
| 61 |
|
U+01d00 - U+01d77 |
| 62 |
|
U+01d9b - U+01dbf |
| 63 |
|
U+0200b - U+0200f |
| 64 |
|
U+030fc - U+030fe |
| 65 |
|
U+03260 - U+0327f |
| 66 |
|
U+0fb46 - U+0fbb1 |
| 67 |
|
U+10450 - U+1049d |
| 68 |
|
|
| 69 |
|
12. The -o option (show only the matching part of a line) for pcregrep was not |
| 70 |
|
compatible with GNU grep in that, if there was more than one match in a |
| 71 |
|
line, it showed only the first of them. It now behaves in the same way as |
| 72 |
|
GNU grep. |
| 73 |
|
|
| 74 |
|
13. If the -o and -v options were combined for pcregrep, it printed a blank |
| 75 |
|
line for every non-matching line. GNU grep prints nothing, and pcregrep now |
| 76 |
|
does the same. The return code can be used to tell if there were any |
| 77 |
|
non-matching lines. |
| 78 |
|
|
| 79 |
|
14. The pattern (?=something)(?R) was not being diagnosed as a potentially |
| 80 |
|
infinitely looping recursion. The bug was that positive lookaheads were not |
| 81 |
|
being skipped when checking for a possible empty match (negative lookaheads |
| 82 |
|
and both kinds of lookbehind were skipped). |
| 83 |
|
|
| 84 |
|
|
| 85 |
Version 7.4 21-Sep-07 |
Version 7.4 21-Sep-07 |
Parent Directory
| 
Revision Log
| 
Patch