--- code/trunk/ChangeLog	2007/08/20 11:07:53	223
+++ code/trunk/ChangeLog	2007/09/14 09:14:24	244
@@ -1,7 +1,65 @@
 ChangeLog for PCRE
 ------------------
 
-Version 7.3 20-Aug-07
+Version 7.4 10-Sep-07
+---------------------
+
+1.  Change 7.3/28 was implemented for classes by looking at the bitmap. This
+    means that a class such as [\s] counted as "explicit reference to CR or
+    LF". That isn't really right - the whole point of the change was to try to
+    help when there was an actual mention of one of the two characters. So now
+    the change happens only if \r or \n (or a literal CR or LF) character is
+    encountered.
+
+2.  The 32-bit options word was also used for 6 internal flags, but the numbers
+    of both had grown to the point where there were only 3 bits left.
+    Fortunately, there was spare space in the data structure, and so I have
+    moved the internal flags into a new 16-bit field to free up more option
+    bits.
+
+3.  The appearance of (?J) at the start of a pattern set the DUPNAMES option,
+    but did not set the internal JCHANGED flag - either of these is enough to
+    control the way the "get" function works - but the PCRE_INFO_JCHANGED
+    facility is supposed to tell if (?J) was ever used, so now (?J) at the
+    start sets both bits.
+
+4.  Added options (at build time, compile time, exec time) to change \R from
+    matching any Unicode line ending sequence to just matching CR, LF, or CRLF.
+
+5.  doc/pcresyntax.html was missing from the distribution.
+
+6.  Put back the definition of PCRE_ERROR_NULLWSLIMIT, for backward
+    compatibility, even though it is no longer used.
+
+7.  Added macro for snprintf to pcrecpp_unittest.cc and also for strtoll and
+    strtoull to pcrecpp.cc to select the available functions in WIN32 (where
+    different names are used).
+
+8.  Changed all #include <config.h> to #include "config.h". There were also
+    some further <pcre.h> cases that I changed to "pcre.h".
+
+9.  When pcregrep was used with the --colour option, it missed the line ending
+    sequence off the lines that it output.
+
+10. It was pointed out to me that arrays of string pointers cause lots of
+    relocations when a shared library is dynamically loaded. A technique of
+    using a single long string with a table of offsets can drastically reduce
+    these. I have refactored PCRE in four places to do this. The result is
+    dramatic:
+
+      Originally:                          290
+      After changing UCP table:            187
+      After changing error message table:   43
+      After changing table of "verbs"       36
+      After changing table of Posix names   22
+
+    Thanks to the folks working on Gregex for glib for this insight.
+    
+11. --disable-stack-for-recursion caused compiling to fail unless -enable-
+    unicode-properties was also set. 
+
+
+Version 7.3 28-Aug-07
 ---------------------
 
  1. In the rejigging of the build system that eventually resulted in 7.1, the
@@ -145,9 +203,26 @@
 
 25. Using pcregrep in multiline, inverted mode (-Mv) caused it to loop.
 
-26. Patterns such as [\P{Yi}A] which include \p or \P and just one other 
+26. Patterns such as [\P{Yi}A] which include \p or \P and just one other
     character were causing crashes (broken optimization).
 
+27. Patterns such as (\P{Yi}*\277)* (group with possible zero repeat containing
+    \p or \P) caused a compile-time loop.
+
+28. More problems have arisen in unanchored patterns when CRLF is a valid line
+    break. For example, the unstudied pattern [\r\n]A does not match the string
+    "\r\nA" because change 7.0/46 below moves the current point on by two
+    characters after failing to match at the start. However, the pattern \nA
+    *does* match, because it doesn't start till \n, and if [\r\n]A is studied,
+    the same is true. There doesn't seem any very clean way out of this, but
+    what I have chosen to do makes the common cases work: PCRE now takes note
+    of whether there can be an explicit match for \r or \n anywhere in the
+    pattern, and if so, 7.0/46 no longer applies. As part of this change,
+    there's a new PCRE_INFO_HASCRORLF option for finding out whether a compiled
+    pattern has explicit CR or LF references.
+
+29. Added (*CR) etc for changing newline setting at start of pattern.
+
 
 Version 7.2 19-Jun-07
 ---------------------