/[pcre]/code/branches/pcre16/ChangeLog
ViewVC logotype

Diff of /code/branches/pcre16/ChangeLog

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 219 by ph10, Thu Aug 16 11:46:40 2007 UTC revision 228 by ph10, Tue Aug 28 13:37:37 2007 UTC
# Line 1  Line 1 
1  ChangeLog for PCRE  ChangeLog for PCRE
2  ------------------  ------------------
3    
4  Version 7.3 09-Aug-07  Version 7.3 28-Aug-07
5  ---------------------  ---------------------
6    
7   1. In the rejigging of the build system that eventually resulted in 7.1, the   1. In the rejigging of the build system that eventually resulted in 7.1, the
# Line 98  Version 7.3 09-Aug-07 Line 98  Version 7.3 09-Aug-07
98      the "low surrogate" sequence 0xD800 to 0xDFFF. Previously, PCRE allowed the      the "low surrogate" sequence 0xD800 to 0xDFFF. Previously, PCRE allowed the
99      full range 0 to 0x7FFFFFFF, as defined by RFC 2279. Internally, it still      full range 0 to 0x7FFFFFFF, as defined by RFC 2279. Internally, it still
100      does: it's just the validity check that is more restrictive.      does: it's just the validity check that is more restrictive.
101    
102  16. Inserted checks for integer overflows during escape sequence (backslash)  16. Inserted checks for integer overflows during escape sequence (backslash)
103      processing, and also fixed erroneous offset values for syntax errors during      processing, and also fixed erroneous offset values for syntax errors during
104      backslash processing.      backslash processing.
105    
106  17. Fixed another case of looking too far back in non-UTF-8 mode (cf 12 above)  17. Fixed another case of looking too far back in non-UTF-8 mode (cf 12 above)
107      for patterns like [\PPP\x8a]{1,}\x80 with the subject "A\x80".      for patterns like [\PPP\x8a]{1,}\x80 with the subject "A\x80".
108    
109  18. An unterminated class in a pattern like (?1)\c[ with a "forward reference"  18. An unterminated class in a pattern like (?1)\c[ with a "forward reference"
110      caused an overrun.      caused an overrun.
111    
112  19. A pattern like (?:[\PPa*]*){8,} which had an "extended class" (one with  19. A pattern like (?:[\PPa*]*){8,} which had an "extended class" (one with
113      something other than just ASCII characters) inside a group that had an      something other than just ASCII characters) inside a group that had an
114      unlimited repeat caused a loop at compile time (while checking to see      unlimited repeat caused a loop at compile time (while checking to see
115      whether the group could match an empty string).      whether the group could match an empty string).
116    
117  20. Debugging a pattern containing \p or \P could cause a crash. For example,  20. Debugging a pattern containing \p or \P could cause a crash. For example,
118      [\P{Any}] did so. (Error in the code for printing property names.)      [\P{Any}] did so. (Error in the code for printing property names.)
   
 21. An orphan \E inside a character class could cause a crash.  
119    
120  22. A repeated capturing bracket such as (A)? could cause a wild memory  21. An orphan \E inside a character class could cause a crash.
121    
122    22. A repeated capturing bracket such as (A)? could cause a wild memory
123      reference during compilation.      reference during compilation.
124    
125  23. There are several functions in pcre_compile() that scan along a compiled  23. There are several functions in pcre_compile() that scan along a compiled
126      expression for various reasons (e.g. to see if it's fixed length for look      expression for various reasons (e.g. to see if it's fixed length for look
127      behind). There were bugs in these functions when a repeated \p or \P was      behind). There were bugs in these functions when a repeated \p or \P was
128      present in the pattern. These operators have additional parameters compared      present in the pattern. These operators have additional parameters compared
129      with \d, etc, and these were not being taken into account when moving along      with \d, etc, and these were not being taken into account when moving along
130      the compiled data. Specifically:      the compiled data. Specifically:
131    
132      (a) A item such as \p{Yi}{3} in a lookbehind was not treated as fixed      (a) A item such as \p{Yi}{3} in a lookbehind was not treated as fixed
133          length.          length.
134    
135      (b) An item such as \pL+ within a repeated group could cause crashes or      (b) An item such as \pL+ within a repeated group could cause crashes or
136          loops.          loops.
137    
138      (c) A pattern such as \p{Yi}+(\P{Yi}+)(?1) could give an incorrect      (c) A pattern such as \p{Yi}+(\P{Yi}+)(?1) could give an incorrect
139          "reference to non-existent subpattern" error.          "reference to non-existent subpattern" error.
140    
141        (d) A pattern like (\P{Yi}{2}\277)? could loop at compile time.
142    
143  24. A repeated \S or \W in UTF-8 mode could give wrong answers when multibyte  24. A repeated \S or \W in UTF-8 mode could give wrong answers when multibyte
144      characters were involved (for example /\S{2}/8g with "A\x{a3}BC").      characters were involved (for example /\S{2}/8g with "A\x{a3}BC").
145    
146    25. Using pcregrep in multiline, inverted mode (-Mv) caused it to loop.
147    
148    26. Patterns such as [\P{Yi}A] which include \p or \P and just one other
149        character were causing crashes (broken optimization).
150    
151    27. Patterns such as (\P{Yi}*\277)* (group with possible zero repeat containing
152        \p or \P) caused a compile-time loop.
153    
154    28. More problems have arisen in unanchored patterns when CRLF is a valid line
155        break. For example, the unstudied pattern [\r\n]A does not match the string
156        "\r\nA" because change 7.0/46 below moves the current point on by two
157        characters after failing to match at the start. However, the pattern \nA
158        *does* match, because it doesn't start till \n, and if [\r\n]A is studied,
159        the same is true. There doesn't seem any very clean way out of this, but
160        what I have chosen to do makes the common cases work: PCRE now takes note
161        of whether there can be an explicit match for \r or \n anywhere in the
162        pattern, and if so, 7.0/46 no longer applies. As part of this change,
163        there's a new PCRE_INFO_HASCRORLF option for finding out whether a compiled
164        pattern has explicit CR or LF references.
165    
166    29. Added (*CR) etc for changing newline setting at start of pattern.
167    
168    
169  Version 7.2 19-Jun-07  Version 7.2 19-Jun-07

Legend:
Removed from v.219  
changed lines
  Added in v.228

  ViewVC Help
Powered by ViewVC 1.1.5