--- code/trunk/ChangeLog	2007/07/30 13:44:50	196
+++ code/trunk/ChangeLog	2007/07/31 10:50:18	197
@@ -9,13 +9,13 @@
     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.   
-    
+
+    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
@@ -23,17 +23,30 @@
     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.  
-    
+
+ 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" for long printing in the pcrecpp
-    unittest when running under MinGW.  
-    
- 6. ESC_K was left out of the EBCDIC table. 
+    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.
 
 
 Version 7.2 19-Jun-07