| 52 |
comments when looking ahead for named forward references to subpatterns, |
comments when looking ahead for named forward references to subpatterns, |
| 53 |
the only newline sequence it recognized was NL. It now handles newlines |
the only newline sequence it recognized was NL. It now handles newlines |
| 54 |
according to the set newline convention. |
according to the set newline convention. |
| 55 |
|
|
| 56 |
|
8. SunOS4 doesn't have strerror() or strtoul(); pcregrep dealt with the |
| 57 |
|
former, but used strtoul(), whereas pcretest avoided strtoul() but did not |
| 58 |
|
cater for a lack of strerror(). These oversights have been fixed. |
| 59 |
|
|
| 60 |
|
9. Added --match-limit and --recursion-limit to pcregrep. |
| 61 |
|
|
| 62 |
|
10. Added two casts needed to build with Visual Studio when NO_RECURSE is set. |
| 63 |
|
|
| 64 |
|
11. When the -o option was used, pcregrep was setting a return code of 1, even |
| 65 |
|
when matches were found, and --line-buffered was not being honoured. |
| 66 |
|
|
| 67 |
|
12. Added an optional parentheses number to the -o and --only-matching options |
| 68 |
|
of pcregrep. |
| 69 |
|
|
| 70 |
|
13. Imitating Perl's /g action for multiple matches is tricky when the pattern |
| 71 |
|
can match an empty string. The code to do it in pcretest and pcredemo |
| 72 |
|
needed fixing: |
| 73 |
|
|
| 74 |
|
(a) When the newline convention was "crlf", pcretest got it wrong, skipping |
| 75 |
|
only one byte after an empty string match just before CRLF (this case |
| 76 |
|
just got forgotten; "any" and "anycrlf" were OK). |
| 77 |
|
|
| 78 |
|
(b) The pcretest code also had a bug, causing it to loop forever in UTF-8 |
| 79 |
|
mode when an empty string match preceded an ASCII character followed by |
| 80 |
|
a non-ASCII character. (The code for advancing by one character rather |
| 81 |
|
than one byte was nonsense.) |
| 82 |
|
|
| 83 |
|
(c) The pcredemo.c sample program did not have any code at all to handle |
| 84 |
|
the cases when CRLF is a valid newline sequence. |
| 85 |
|
|
| 86 |
|
14. Neither pcre_exec() nor pcre_dfa_exec() was checking that the value given |
| 87 |
|
as a starting offset was within the subject string. There is now a new |
| 88 |
|
error, PCRE_ERROR_BADOFFSET, which is returned if the starting offset is |
| 89 |
|
negative or greater than the length of the string. In order to test this, |
| 90 |
|
pcretest is extended to allow the setting of negative starting offsets. |
| 91 |
|
|
| 92 |
|
15. In both pcre_exec() and pcre_dfa_exec() the code for checking that the |
| 93 |
|
starting offset points to the beginning of a UTF-8 character was |
| 94 |
|
unnecessarily clumsy. I tidied it up. |
| 95 |
|
|
| 96 |
|
16. Added PCRE_ERROR_SHORTUTF8 to make it possible to distinguish between a |
| 97 |
|
bad UTF-8 sequence and one that is incomplete. |
| 98 |
|
|
| 99 |
|
17. Nobody had reported that the --include_dir option, which was added in |
| 100 |
|
release 7.7 should have been called --include-dir (hyphen, not underscore) |
| 101 |
|
for compatibility with GNU grep. I have changed it to --include-dir, but |
| 102 |
|
left --include_dir as an undocumented synonym, and the same for |
| 103 |
|
--exclude-dir, though that is not available in GNU grep, at least as of |
| 104 |
|
release 2.5.4. |
| 105 |
|
|
| 106 |
|
18. At a user's suggestion, the macros GETCHAR and friends (which pick up UTF-8 |
| 107 |
|
characters from a string of bytes) have been redefined so as not to use |
| 108 |
|
loops, in order to improve performance in some environments. At the same |
| 109 |
|
time, I abstracted some of the common code into auxiliary macros to save |
| 110 |
|
repetition (this should not affect the compiled code). |
| 111 |
|
|
| 112 |
|
|
| 113 |
Version 8.10 25-Jun-2010 |
Version 8.10 25-Jun-2010 |
Parent Directory
| 
Revision Log
| 
Patch