| 1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
| 2 |
------------------ |
------------------ |
| 3 |
|
|
| 4 |
Version 8.12 11-Jan-2011 |
Version 8.13 30-Apr-2011 |
| 5 |
|
------------------------ |
| 6 |
|
|
| 7 |
|
1. The Unicode data tables have been updated to Unicode 6.0.0. |
| 8 |
|
|
| 9 |
|
2. Two minor typos in pcre_internal.h have been fixed. |
| 10 |
|
|
| 11 |
|
3. Added #include <string.h> to pcre_scanner_unittest.cc, pcrecpp.cc, and |
| 12 |
|
pcrecpp_unittest.cc. They are needed for strcmp(), memset(), and strchr() |
| 13 |
|
in some environments (e.g. Solaris 10/SPARC using Sun Studio 12U2). |
| 14 |
|
|
| 15 |
|
4. There were a number of related bugs in the code for matching backrefences |
| 16 |
|
caselessly in UTF-8 mode when codes for the characters concerned were |
| 17 |
|
different numbers of bytes. For example, U+023A and U+2C65 are an upper |
| 18 |
|
and lower case pair, using 2 and 3 bytes, respectively. The main bugs were: |
| 19 |
|
(a) A reference to 3 copies of a 2-byte code matched only 2 of a 3-byte |
| 20 |
|
code. (b) A reference to 2 copies of a 3-byte code would not match 2 of a |
| 21 |
|
2-byte code at the end of the subject (it thought there wasn't enough data |
| 22 |
|
left). |
| 23 |
|
|
| 24 |
|
5. Comprehensive information about what went wrong is now returned by |
| 25 |
|
pcre_exec() and pcre_dfa_exec() when the UTF-8 string check fails, as long |
| 26 |
|
as the output vector has at least 2 elements. The offset of the start of |
| 27 |
|
the failing character and a reason code are placed in the vector. |
| 28 |
|
|
| 29 |
|
6. When the UTF-8 string check fails for pcre_compile(), the offset that is |
| 30 |
|
now returned is for the first byte of the failing character, instead of the |
| 31 |
|
last byte inspected. This is an incompatible change, but I hope it is small |
| 32 |
|
enough not to be a problem. It makes the returned offset consistent with |
| 33 |
|
pcre_exec() and pcre_dfa_exec(). |
| 34 |
|
|
| 35 |
|
7. pcretest now gives a text phrase as well as the error number when |
| 36 |
|
pcre_exec() or pcre_dfa_exec() fails; if the error is a UTF-8 check |
| 37 |
|
failure, the offset and reason code are output. |
| 38 |
|
|
| 39 |
|
8. When \R was used with a maximizing quantifier it failed to skip backwards |
| 40 |
|
over a \r\n pair if the subsequent match failed. Instead, it just skipped |
| 41 |
|
back over a single character (\n). This seems wrong (because it treated the |
| 42 |
|
two characters as a single entity when going forwards), conflicts with the |
| 43 |
|
documentation that \R is equivalent to (?>\r\n|\n|...etc), and makes the |
| 44 |
|
behaviour of \R* different to (\R)*, which also seems wrong. The behaviour |
| 45 |
|
has been changed. |
| 46 |
|
|
| 47 |
|
|
| 48 |
|
Version 8.12 15-Jan-2011 |
| 49 |
------------------------ |
------------------------ |
| 50 |
|
|
| 51 |
1. Fixed some typos in the markup of the man pages, and wrote a script that |
1. Fixed some typos in the markup of the man pages, and wrote a script that |
| 52 |
checks for such things as part of the documentation building process. |
checks for such things as part of the documentation building process. |
| 53 |
|
|
| 54 |
|
2. On a big-endian 64-bit system, pcregrep did not correctly process the |
| 55 |
|
--match-limit and --recursion-limit options (added for 8.11). In |
| 56 |
|
particular, this made one of the standard tests fail. (The integer value |
| 57 |
|
went into the wrong half of a long int.) |
| 58 |
|
|
| 59 |
|
3. If the --colour option was given to pcregrep with -v (invert match), it |
| 60 |
|
did strange things, either producing crazy output, or crashing. It should, |
| 61 |
|
of course, ignore a request for colour when reporting lines that do not |
| 62 |
|
match. |
| 63 |
|
|
| 64 |
|
4. Another pcregrep bug caused similar problems if --colour was specified with |
| 65 |
|
-M (multiline) and the pattern match finished with a line ending. |
| 66 |
|
|
| 67 |
|
5. In pcregrep, when a pattern that ended with a literal newline sequence was |
| 68 |
|
matched in multiline mode, the following line was shown as part of the |
| 69 |
|
match. This seems wrong, so I have changed it. |
| 70 |
|
|
| 71 |
|
6. Another pcregrep bug in multiline mode, when --colour was specified, caused |
| 72 |
|
the check for further matches in the same line (so they could be coloured) |
| 73 |
|
to overrun the end of the current line. If another match was found, it was |
| 74 |
|
incorrectly shown (and then shown again when found in the next line). |
| 75 |
|
|
| 76 |
|
7. If pcregrep was compiled under Windows, there was a reference to the |
| 77 |
|
function pcregrep_exit() before it was defined. I am assuming this was |
| 78 |
|
the cause of the "error C2371: 'pcregrep_exit' : redefinition;" that was |
| 79 |
|
reported by a user. I've moved the definition above the reference. |
| 80 |
|
|
| 81 |
|
|
| 82 |
Version 8.11 10-Dec-2010 |
Version 8.11 10-Dec-2010 |
| 83 |
------------------------ |
------------------------ |
Parent Directory
| 
Revision Log
| 
Patch