| 13 |
|
|
| 14 |
3. The same bug as (2) above applied to negated POSIX classes such as |
3. The same bug as (2) above applied to negated POSIX classes such as |
| 15 |
[:^space:]. |
[:^space:]. |
| 16 |
|
|
| 17 |
|
4. PCRECPP_STATIC was referenced in pcrecpp_internal.h, but nowhere was it |
| 18 |
|
defined or documented. It seems to have been a typo for PCRE_STATIC, so |
| 19 |
|
I have changed it. |
| 20 |
|
|
| 21 |
|
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 |
| 23 |
|
first named subpattern whose name started with "a" (in other words, the |
| 24 |
|
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; |
| 30 |
|
this is right because (?- can be followed by option settings as well as by |
| 31 |
|
digits. I have, however, made the messages clearer. |
| 32 |
|
|
| 33 |
|
7. Patterns such as (?(1)a|b) (a pattern that contains fewer subpatterns |
| 34 |
|
than the number used in the conditional) now cause a compile-time error. |
| 35 |
|
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 |
| 37 |
|
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 |
|
|
| 80 |
Version 7.4 21-Sep-07 |
Version 7.4 21-Sep-07 |
Parent Directory
| 
Revision Log
| 
Patch