| 26 |
but it seems right to fix it, and I didn't think it was worth preserving |
but it seems right to fix it, and I didn't think it was worth preserving |
| 27 |
the old behaviour. |
the old behaviour. |
| 28 |
|
|
| 29 |
|
5. The command line items --regex=pattern and --regexp=pattern were not |
| 30 |
|
recognized by pcregrep, which required --regex pattern or --regexp pattern |
| 31 |
|
(with a space rather than an '='). The man page documented the '=' forms, |
| 32 |
|
which are compatible with GNU grep; these now work. |
| 33 |
|
|
| 34 |
|
6. No libpcreposix.pc file was created for pkg-config; there was just |
| 35 |
|
libpcre.pc and libpcrecpp.pc. The omission has been rectified. |
| 36 |
|
|
| 37 |
|
7. Added #ifndef SUPPORT_UCP into the pcre_ucd.c module, to reduce its size |
| 38 |
|
when UCP support is not needed, by modifying the Python script that |
| 39 |
|
generates it from Unicode data files. This should not matter if the module |
| 40 |
|
is correctly used as a library, but I received one complaint about 50K of |
| 41 |
|
unwanted data. My guess is that the person linked everything into his |
| 42 |
|
program rather than using a library. Anyway, it does no harm. |
| 43 |
|
|
| 44 |
|
8. A pattern such as /\x{123}{2,2}+/8 was incorrectly compiled; the trigger |
| 45 |
|
was a minimum greater than 1 for a wide character in a possessive |
| 46 |
|
repetition. The same bug could also affect patterns like /(\x{ff}{0,2})*/8 |
| 47 |
|
which had an unlimited repeat of a nested, fixed maximum repeat of a wide |
| 48 |
|
character. Chaos in the form of incorrect output or a compiling loop could |
| 49 |
|
result. |
| 50 |
|
|
| 51 |
|
9. The restrictions on what a pattern can contain when partial matching is |
| 52 |
|
requested for pcre_exec() have been removed. All patterns can now be |
| 53 |
|
partially matched by this function. In addition, if there are at least two |
| 54 |
|
slots in the offset vector, the offset of the earliest inspected character |
| 55 |
|
for the match and the offset of the end of the subject are set in them when |
| 56 |
|
PCRE_ERROR_PARTIAL is returned. |
| 57 |
|
|
| 58 |
|
10. Partial matching has been split into two forms: PCRE_PARTIAL_SOFT, which is |
| 59 |
|
synonymous with PCRE_PARTIAL, for backwards compatibility, and |
| 60 |
|
PCRE_PARTIAL_HARD, which causes a partial match to supersede a full match, |
| 61 |
|
and may be more useful for multi-segment matching, especially with |
| 62 |
|
pcre_exec(). |
| 63 |
|
|
| 64 |
|
11. Partial matching with pcre_exec() is now more intuitive. A partial match |
| 65 |
|
used to be given if ever the end of the subject was reached; now it is |
| 66 |
|
given only if matching could not proceed because another character was |
| 67 |
|
needed. This makes a difference in some odd cases such as Z(*FAIL) with the |
| 68 |
|
string "Z", which now yields "no match" instead of "partial match". In the |
| 69 |
|
case of pcre_dfa_exec(), "no match" is given if every matching path for the |
| 70 |
|
final character ended with (*FAIL). |
| 71 |
|
|
| 72 |
|
12. Restarting a match using pcre_dfa_exec() after a partial match did not work |
| 73 |
|
if the pattern had a "must contain" character that was already found in the |
| 74 |
|
earlier partial match, unless partial matching was again requested. For |
| 75 |
|
example, with the pattern /dog.(body)?/, the "must contain" character is |
| 76 |
|
"g". If the first part-match was for the string "dog", restarting with |
| 77 |
|
"sbody" failed. This bug has been fixed. |
| 78 |
|
|
| 79 |
|
13. The string returned by pcre_dfa_exec() after a partial match has been |
| 80 |
|
changed so that it starts at the first inspected character rather than the |
| 81 |
|
first character of the match. This makes a difference only if the pattern |
| 82 |
|
starts with a lookbehind assertion or \b or \B (\K is not supported by |
| 83 |
|
pcre_dfa_exec()). It's an incompatible change, but it makes the two |
| 84 |
|
matching functions compatible, and I think it's the right thing to do. |
| 85 |
|
|
| 86 |
|
14. Added a pcredemo man page, created automatically from the pcredemo.c file, |
| 87 |
|
so that the demonstration program is easily available in environments where |
| 88 |
|
PCRE has not been installed from source. |
| 89 |
|
|
| 90 |
|
15. Arranged to add -DPCRE_STATIC to cflags in libpcre.pc, libpcreposix.cp, |
| 91 |
|
libpcrecpp.pc and pcre-config when PCRE is not compiled as a shared |
| 92 |
|
library. |
| 93 |
|
|
| 94 |
|
16. Added REG_UNGREEDY to the pcreposix interface, at the request of a user. |
| 95 |
|
It maps to PCRE_UNGREEDY. It is not, of course, POSIX-compatible, but it |
| 96 |
|
is not the first non-POSIX option to be added. Clearly some people find |
| 97 |
|
these options useful. |
| 98 |
|
|
| 99 |
|
17. If a caller to the POSIX matching function regexec() passes a non-zero |
| 100 |
|
value for nmatch with a NULL value for pmatch, the value of |
| 101 |
|
nmatch is forced to zero. |
| 102 |
|
|
| 103 |
|
18. RunGrepTest did not have a test for the availability of the -u option of |
| 104 |
|
the diff command, as RunTest does. It now checks in the same way as |
| 105 |
|
RunTest, and also checks for the -b option. |
| 106 |
|
|
| 107 |
|
19. If an odd number of negated classes containing just a single character |
| 108 |
|
interposed, within parentheses, between a forward reference to a named |
| 109 |
|
subpattern and the definition of the subpattern, compilation crashed with |
| 110 |
|
an internal error, complaining that it could not find the referenced |
| 111 |
|
subpattern. An example of a crashing pattern is /(?&A)(([^m])(?<A>))/. |
| 112 |
|
[The bug was that it was starting one character too far in when skipping |
| 113 |
|
over the character class, thus treating the ] as data rather than |
| 114 |
|
terminating the class. This meant it could skip too much.] |
| 115 |
|
|
| 116 |
|
|
| 117 |
Version 7.9 11-Apr-09 |
Version 7.9 11-Apr-09 |
| 118 |
--------------------- |
--------------------- |
Parent Directory
| 
Revision Log
| 
Patch