/[pcre]/code/trunk/ChangeLog

Diff of /code/trunk/ChangeLog

Parent Directory | Revision Log | View Patch Patch

-revision 286 by ph10,
Mon Dec 17 14:46:11 2007 UTC
+revision 309 by ph10,
Mon Jan 21 15:22:09 2008 UTC
 Line 1
  ChangeLog for PCRE
  ------------------
- Version 7.5 12-Nov-07
+ Version 7.6 21-Jan-08
+ ---------------------
+.  A character class containing a very large number of characters with
+     codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer
+     overflow.
+.  Patch to cut out the "long long" test in pcrecpp_unittest when
+     HAVE_LONG_LONG is not defined.
+.  Applied Christian Ehrlicher's patch to update the CMake build files to
+     bring them up to date and include new features. This patch includes:
+     - Fixed PH's badly added libz and libbz2 support.
+     - Fixed a problem with static linking.
+     - Added pcredemo.
+     - Fixed dftables problem and added an option.
+     - Added a number of HAVE_XXX tests, including HAVE_WINDOWS_H and
+         HAVE_LONG_LONG.
+     - Added readline support for pcretest.
+     - Added an listing of the option settings after cmake has run.
+.  A user submitted a patch to Makefile that makes it easy to created a dll
+     under mingw. I added stuff to Makefile.am that cause it to include this
+     special target, without affecting anything else.
+.  Applied Craig's patch that moves no_arg into the RE class in the C++ code.
+     This is an attempt to solve the reported problem "pcrecpp::no_arg is not
+     exported in the Windows port". It has not yet been confirmed that the patch
+     solves the problem, but it does no harm.
+ Version 7.5 10-Jan-08
  ---------------------
 .  Applied a patch from Craig: "This patch makes it possible to 'ignore'
-Line 76 
 Version 7.5 12-Nov-07
+Line 108 
 Version 7.5 12-Nov-07
      does the same. The return code can be used to tell if there were any
      non-matching lines.
-. The pattern (?=something)(?R) was not being diagnosed as a potentially
+. Added --file-offsets and --line-offsets to pcregrep.
+. The pattern (?=something)(?R) was not being diagnosed as a potentially
      infinitely looping recursion. The bug was that positive lookaheads were not
      being skipped when checking for a possible empty match (negative lookaheads
      and both kinds of lookbehind were skipped).
 . Fixed two typos in the Windows-only code in pcregrep.c, and moved the
      inclusion of <windows.h> to before rather than after the definition of
      INVALID_FILE_ATTRIBUTES (patch from David Byron).
 . Specifying a possessive quantifier with a specific limit for a Unicode
      character property caused pcre_compile() to compile bad code, which led at
      runtime to PCRE_ERROR_INTERNAL (-14). Examples of patterns that caused this
      are: /\p{Zl}{2,3}+/8 and /\p{Cc}{2}+/8. It was the possessive "+" that
      caused the error; without that there was no problem.
 . Added --enable-pcregrep-libz and --enable-pcregrep-libbz2.
+. Added --enable-pcretest-libreadline.
+. In pcrecpp.cc, the variable 'count' was incremented twice in
+     RE::GlobalReplace(). As a result, the number of replacements returned was
+     double what it should be. I removed one of the increments, but Craig sent a
+     later patch that removed the other one (the right fix) and added unit tests
+     that check the return values (which was not done before).
+. Several CMake things:
+     (1) Arranged that, when cmake is used on Unix, the libraries end up with
+         the names libpcre and libpcreposix, not just pcre and pcreposix.
+     (2) The above change means that pcretest and pcregrep are now correctly
+         linked with the newly-built libraries, not previously installed ones.
+     (3) Added PCRE_SUPPORT_LIBREADLINE, PCRE_SUPPORT_LIBZ, PCRE_SUPPORT_LIBBZ2.
+. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.*
+     crashed when matching a string such as a\x{2029}b (note that \x{2029} is a
+     UTF-8 newline character). The key issue is that the pattern starts .*;
+     this means that the match must be either at the beginning, or after a
+     newline. The bug was in the code for advancing after a failed match and
+     checking that the new position followed a newline. It was not taking
+     account of UTF-8 characters correctly.
+. PCRE was behaving differently from Perl in the way it recognized POSIX
+     character classes. PCRE was not treating the sequence [:...:] as a
+     character class unless the ... were all letters. Perl, however, seems to
+     allow any characters between [: and :], though of course it rejects as
+     unknown any "names" that contain non-letters, because all the known class
+     names consist only of letters. Thus, Perl gives an error for [[:1234:]],
+     for example, whereas PCRE did not - it did not recognize a POSIX character
+     class. This seemed a bit dangerous, so the code has been changed to be
+     closer to Perl. The behaviour is not identical to Perl, because PCRE will
+     diagnose an unknown class for, for example, [[:l\ower:]] where Perl will
+     treat it as [[:lower:]]. However, PCRE does now give "unknown" errors where
+     Perl does, and where it didn't before.
+. Rewrite so as to remove the single use of %n from pcregrep because in some
+     Windows environments %n is disabled by default.
  Version 7.4 21-Sep-07

 Legend:



Removed from v.286
 


changed lines


 
Added in v.309
 Legend:



Removed from v.286
 


changed lines


 
Added in v.309
-Removed from v.286
+Added in v.309

webmaster@exim.org	ViewVC Help
Powered by ViewVC 1.1.12