--- code/trunk/ChangeLog	2008/08/24 18:33:00	370
+++ code/trunk/ChangeLog	2008/08/25 18:28:05	371
@@ -31,47 +31,47 @@
 
 7.  Added two (int) casts to pcregrep when printing the difference of two
     pointers, in case they are 64-bit values.
-    
-8.  Added comments about Mac OS X stack usage to the pcrestack man page and to 
-    test 2 if it fails. 
-    
+
+8.  Added comments about Mac OS X stack usage to the pcrestack man page and to
+    test 2 if it fails.
+
 9.  Added PCRE_CALL_CONVENTION just before the names of all exported functions,
-    and a #define of that name to empty if it is not externally set. This is to 
-    allow users of MSVC to set it if necessary.  
-    
-10. The PCRE_EXP_DEFN macro which precedes exported functions was missing from 
+    and a #define of that name to empty if it is not externally set. This is to
+    allow users of MSVC to set it if necessary.
+
+10. The PCRE_EXP_DEFN macro which precedes exported functions was missing from
     the convenience functions in the pcre_get.c source file.
-    
+
 11. An option change at the start of a pattern that had top-level alternatives
     could cause overwriting and/or a crash. This command provoked a crash in
-    some environments: 
-     
-      printf "/(?i)[\xc3\xa9\xc3\xbd]|[\xc3\xa9\xc3\xbdA]/8\n" | pcretest  
-      
+    some environments:
+
+      printf "/(?i)[\xc3\xa9\xc3\xbd]|[\xc3\xa9\xc3\xbdA]/8\n" | pcretest
+
     This potential security problem was recorded as CVE-2008-2371.
-    
+
 12. For a pattern where the match had to start at the beginning or immediately
     after a newline (e.g /.*anything/ without the DOTALL flag), pcre_exec() and
-    pcre_dfa_exec() could read past the end of the passed subject if there was 
+    pcre_dfa_exec() could read past the end of the passed subject if there was
     no match. To help with detecting such bugs (e.g. with valgrind), I modified
     pcretest so that it places the subject at the end of its malloc-ed buffer.
-    
+
 13. The change to pcretest in 12 above threw up a couple more cases when pcre_
-    exec() might read past the end of the data buffer in UTF-8 mode. 
-    
+    exec() might read past the end of the data buffer in UTF-8 mode.
+
 14. A similar bug to 7.3/2 existed when the PCRE_FIRSTLINE option was set and
-    the data contained the byte 0x85 as part of a UTF-8 character within its 
-    first line. This applied both to normal and DFA matching. 
-    
+    the data contained the byte 0x85 as part of a UTF-8 character within its
+    first line. This applied both to normal and DFA matching.
+
 15. Lazy qualifiers were not working in some cases in UTF-8 mode. For example,
-    /^[^d]*?$/8 failed to match "abc". 
-    
-16. Added a missing copyright notice to pcrecpp_internal.h. 
+    /^[^d]*?$/8 failed to match "abc".
+
+16. Added a missing copyright notice to pcrecpp_internal.h.
 
-17. Make it more clear in the documentation that values returned from 
+17. Make it more clear in the documentation that values returned from
     pcre_exec() in ovector are byte offsets, not character counts.
-    
-18. Tidied a few places to stop certain compilers from issuing warnings. 
+
+18. Tidied a few places to stop certain compilers from issuing warnings.
 
 
 Version 7.7 07-May-08