--- code/trunk/ChangeLog	2007/06/19 13:26:46	184
+++ code/trunk/ChangeLog	2007/08/03 10:09:57	203
@@ -1,7 +1,77 @@
 ChangeLog for PCRE
 ------------------
 
-Version 7.2 19-June-07
+Version 7.3 05-Jul-07
+---------------------
+
+ 1. In the rejigging of the build system that eventually resulted in 7.1, the
+    line "#include <pcre.h>" was included in pcre_internal.h. The use of angle
+    brackets there is not right, since it causes compilers to look for an
+    installed pcre.h, not the version that is in the source that is being
+    compiled (which of course may be different). I have changed it back to:
+
+      #include "pcre.h"
+
+    I have a vague recollection that the change was concerned with compiling in
+    different directories, but in the new build system, that is taken care of
+    by the VPATH setting the Makefile.
+
+ 2. The pattern .*$ when run in not-DOTALL UTF-8 mode with newline=any failed
+    when the subject happened to end in the byte 0x85 (e.g. if the last
+    character was \x{1ec5}). *Character* 0x85 is one of the "any" newline
+    characters but of course it shouldn't be taken as a newline when it is part
+    of another character. The bug was that, for an unlimited repeat of . in
+    not-DOTALL UTF-8 mode, PCRE was advancing by bytes rather than by
+    characters when looking for a newline.
+
+ 3. A small performance improvement in the DOTALL UTF-8 mode .* case.
+
+ 4. Debugging: adjusted the names of opcodes for different kinds of parentheses
+    in debug output.
+
+ 5. Arrange to use "%I64d" instead of "%lld" and "%I64u" instead of "%llu" for
+    long printing in the pcrecpp unittest when running under MinGW.
+
+ 6. ESC_K was left out of the EBCDIC table.
+
+ 7. Change 7.0/38 introduced a new limit on the number of nested non-capturing
+    parentheses; I made it 1000, which seemed large enough. Unfortunately, the
+    limit also applies to "virtual nesting" when a pattern is recursive, and in
+    this case 1000 isn't so big. I have been able to remove this limit at the
+    expense of backing off one optimization in certain circumstances. Normally,
+    when pcre_exec() would call its internal match() function recursively and
+    immediately return the result unconditionally, it uses a "tail recursion"
+    feature to save stack. However, when a subpattern that can match an empty
+    string has an unlimited repetition quantifier, it no longer makes this
+    optimization. That gives it a stack frame in which to save the data for
+    checking that an empty string has been matched. Previously this was taken
+    from the 1000-entry workspace that had been reserved. So now there is no
+    explicit limit, but more stack is used.
+
+ 8. Applied Daniel's patches to solve problems with the import/export magic
+    syntax that is required for Windows, and which was going wrong for the
+    pcreposix and pcrecpp parts of the library. These were overlooked when this
+    problem was solved for the main library.
+
+ 9. There were some crude static tests to avoid integer overflow when computing
+    the size of patterns that contain repeated groups with explicit upper
+    limits. As the maximum quantifier is 65535, the maximum group length was
+    set at 30,000 so that the product of these two numbers did not overflow a
+    32-bit integer. However, it turns out that people want to use groups that
+    are longer than 30,000 bytes (though not repeat them that many times).
+    Change 7.0/17 (the refactoring of the way the pattern size is computed) has
+    made it possible to implement the integer overflow checks in a much more
+    dynamic way, which I have now done. The artificial limitation on group
+    length has been removed - we now have only the limit on the total length of
+    the compiled pattern, which depends on the LINK_SIZE setting.
+    
+10. Fixed a bug in the documentation for get/copy named substring when 
+    duplicate names are permitted. If none of the named substrings are set, the 
+    functions return PCRE_ERROR_NOSUBSTRING (7); the doc said they returned an 
+    empty string. 
+
+
+Version 7.2 19-Jun-07
 ---------------------
 
  1. If the fr_FR locale cannot be found for test 3, try the "french" locale,
@@ -68,9 +138,9 @@
       pcrecpp::RE("a*").FullMatch("aaa") matches, while
       pcrecpp::RE("a*?").FullMatch("aaa") does not, and
       pcrecpp::RE("a*?\\z").FullMatch("aaa") does again.
-      
+
 12. If \p or \P was used in non-UTF-8 mode on a character greater than 127
-    it matched the wrong number of bytes. 
+    it matched the wrong number of bytes.
 
 
 Version 7.1 24-Apr-07