1 |
News about PCRE releases |
News about PCRE releases |
2 |
------------------------ |
------------------------ |
3 |
|
|
4 |
|
Release 5.0 13-Sep-04 |
5 |
|
--------------------- |
6 |
|
|
7 |
|
The licence under which PCRE is released has been changed to the more |
8 |
|
conventional "BSD" licence. |
9 |
|
|
10 |
|
In the code, some bugs have been fixed, and there are also some major changes |
11 |
|
in this release (which is why I've increased the number to 5.0). Some changes |
12 |
|
are internal rearrangements, and some provide a number of new facilities. The |
13 |
|
new features are: |
14 |
|
|
15 |
|
1. There's an "automatic callout" feature that inserts callouts before every |
16 |
|
item in the regex, and there's a new callout field that gives the position |
17 |
|
in the pattern - useful for debugging and tracing. |
18 |
|
|
19 |
|
2. The extra_data structure can now be used to pass in a set of character |
20 |
|
tables at exec time. This is useful if compiled regex are saved and re-used |
21 |
|
at a later time when the tables may not be at the same address. If the |
22 |
|
default internal tables are used, the pointer saved with the compiled |
23 |
|
pattern is now set to NULL, which means that you don't need to do anything |
24 |
|
special unless you are using custom tables. |
25 |
|
|
26 |
|
3. It is possible, with some restrictions on the content of the regex, to |
27 |
|
request "partial" matching. A special return code is given if all of the |
28 |
|
subject string matched part of the regex. This could be useful for testing |
29 |
|
an input field as it is being typed. |
30 |
|
|
31 |
|
4. There is now some optional support for Unicode character properties, which |
32 |
|
means that the patterns items such as \p{Lu} and \X can now be used. Only |
33 |
|
the general category properties are supported. If PCRE is compiled with this |
34 |
|
support, an additional 90K data structure is include, which increases the |
35 |
|
size of the library dramatically. |
36 |
|
|
37 |
|
5. There is support for saving compiled patterns and re-using them later. |
38 |
|
|
39 |
|
6. There is support for running regular expressions that were compiled on a |
40 |
|
different host with the opposite endianness. |
41 |
|
|
42 |
|
7. The pcretest program has been extended to accommodate the new features. |
43 |
|
|
44 |
|
The main internal rearrangement is that sequences of literal characters are no |
45 |
|
longer handled as strings. Instead, each character is handled on its own. This |
46 |
|
makes some UTF-8 handling easier, and makes the support of partial matching |
47 |
|
possible. Compiled patterns containing long literal strings will be larger as a |
48 |
|
result of this change; I hope that performance will not be much affected. |
49 |
|
|
50 |
|
|
51 |
|
Release 4.5 01-Dec-03 |
52 |
|
--------------------- |
53 |
|
|
54 |
|
Again mainly a bug-fix and tidying release, with only a couple of new features: |
55 |
|
|
56 |
|
1. It's possible now to compile PCRE so that it does not use recursive |
57 |
|
function calls when matching. Instead it gets memory from the heap. This slows |
58 |
|
things down, but may be necessary on systems with limited stacks. |
59 |
|
|
60 |
|
2. UTF-8 string checking has been tightened to reject overlong sequences and to |
61 |
|
check that a starting offset points to the start of a character. Failure of the |
62 |
|
latter returns a new error code: PCRE_ERROR_BADUTF8_OFFSET. |
63 |
|
|
64 |
|
3. PCRE can now be compiled for systems that use EBCDIC code. |
65 |
|
|
66 |
|
|
67 |
Release 4.4 21-Aug-03 |
Release 4.4 21-Aug-03 |
68 |
--------------------- |
--------------------- |
69 |
|
|