/[pcre]/code/trunk/ChangeLog

Diff of /code/trunk/ChangeLog

Parent Directory | Revision Log | View Patch Patch

-revision 210 by ph10,
Wed Aug  8 14:24:50 2007 UTC
+revision 231 by ph10,
Tue Sep 11 11:15:33 2007 UTC
 Line 1
  ChangeLog for PCRE
  ------------------
- Version 7.3 05-Jul-07
+ Version 7.4 10-Sep-07
+ ---------------------
+.  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.
+.  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.
+.  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.
+.  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.
+ Version 7.3 28-Aug-07
  ---------------------
 . In the rejigging of the build system that eventually resulted in 7.1, the
-Line 87 
 Version 7.3 05-Jul-07
+Line 113 
 Version 7.3 05-Jul-07
 . A pattern like \X?\d or \P{L}?\d in non-UTF-8 mode could cause a backtrack
      past the start of the subject in the presence of bytes with the top bit
      set, for example "\x8aBCD".
 . Added Perl 5.10 experimental backtracking controls (*FAIL), (*F), (*PRUNE),
      (*SKIP), (*THEN), (*COMMIT), and (*ACCEPT).
 . Optimized (?!) to (*FAIL).
+. Updated the test for a valid UTF-8 string to conform to the later RFC 3629.
+     This restricts code points to be within the range 0 to 0x10FFFF, excluding
+     the "low surrogate" sequence 0xD800 to 0xDFFF. Previously, PCRE allowed the
+     full range 0 to 0x7FFFFFFF, as defined by RFC 2279. Internally, it still
+     does: it's just the validity check that is more restrictive.
+. Inserted checks for integer overflows during escape sequence (backslash)
+     processing, and also fixed erroneous offset values for syntax errors during
+     backslash processing.
+. Fixed another case of looking too far back in non-UTF-8 mode (cf 12 above)
+     for patterns like [\PPP\x8a]{1,}\x80 with the subject "A\x80".
+. An unterminated class in a pattern like (?1)\c[ with a "forward reference"
+     caused an overrun.
+. A pattern like (?:[\PPa*]*){8,} which had an "extended class" (one with
+     something other than just ASCII characters) inside a group that had an
+     unlimited repeat caused a loop at compile time (while checking to see
+     whether the group could match an empty string).
+. Debugging a pattern containing \p or \P could cause a crash. For example,
+     [\P{Any}] did so. (Error in the code for printing property names.)
+. An orphan \E inside a character class could cause a crash.
+. A repeated capturing bracket such as (A)? could cause a wild memory
+     reference during compilation.
+. There are several functions in pcre_compile() that scan along a compiled
+     expression for various reasons (e.g. to see if it's fixed length for look
+     behind). There were bugs in these functions when a repeated \p or \P was
+     present in the pattern. These operators have additional parameters compared
+     with \d, etc, and these were not being taken into account when moving along
+     the compiled data. Specifically:
+     (a) A item such as \p{Yi}{3} in a lookbehind was not treated as fixed
+         length.
+     (b) An item such as \pL+ within a repeated group could cause crashes or
+         loops.
+     (c) A pattern such as \p{Yi}+(\P{Yi}+)(?1) could give an incorrect
+         "reference to non-existent subpattern" error.
+     (d) A pattern like (\P{Yi}{2}\277)? could loop at compile time.
+. A repeated \S or \W in UTF-8 mode could give wrong answers when multibyte
+     characters were involved (for example /\S{2}/8g with "A\x{a3}BC").
+. Using pcregrep in multiline, inverted mode (-Mv) caused it to loop.
+. Patterns such as [\P{Yi}A] which include \p or \P and just one other
+     character were causing crashes (broken optimization).
+. Patterns such as (\P{Yi}*\277)* (group with possible zero repeat containing
+     \p or \P) caused a compile-time loop.
+. 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.
+. Added (*CR) etc for changing newline setting at start of pattern.
  Version 7.2 19-Jun-07

 Legend:



Removed from v.210
 


changed lines


 
Added in v.231
 Legend:



Removed from v.210
 


changed lines


 
Added in v.231
-Removed from v.210
+Added in v.231

webmaster@exim.org	ViewVC Help
Powered by ViewVC 1.1.12