/[pcre]/code/trunk/ChangeLog
ViewVC logotype

Diff of /code/trunk/ChangeLog

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

revision 211 by ph10, Thu Aug 9 09:52:43 2007 UTC revision 226 by ph10, Tue Aug 21 11:46:08 2007 UTC
# Line 1  Line 1 
1  ChangeLog for PCRE  ChangeLog for PCRE
2  ------------------  ------------------
3    
4  Version 7.3 05-Jul-07  Version 7.3 20-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 93  Version 7.3 05-Jul-07 Line 93  Version 7.3 05-Jul-07
93    
94  14. Optimized (?!) to (*FAIL).  14. Optimized (?!) to (*FAIL).
95    
96  15. Updated the test for a valid UTF-8 string to conform to the later RFC 3629.  15. Updated the test for a valid UTF-8 string to conform to the later RFC 3629.
97      This restricts code points to be within the range 0 to 0x10FFFF, excluding      This restricts code points to be within the range 0 to 0x10FFFF, excluding
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)
103        processing, and also fixed erroneous offset values for syntax errors during
104        backslash processing.
105    
106    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".
108    
109    18. An unterminated class in a pattern like (?1)\c[ with a "forward reference"
110        caused an overrun.
111    
112    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
114        unlimited repeat caused a loop at compile time (while checking to see
115        whether the group could match an empty string).
116    
117    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.)
119    
120    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.
124    
125    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
127        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
129        with \d, etc, and these were not being taken into account when moving along
130        the compiled data. Specifically:
131    
132        (a) A item such as \p{Yi}{3} in a lookbehind was not treated as fixed
133            length.
134    
135        (b) An item such as \pL+ within a repeated group could cause crashes or
136            loops.
137    
138        (c) A pattern such as \p{Yi}+(\P{Yi}+)(?1) could give an incorrect
139            "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
144        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    
167  Version 7.2 19-Jun-07  Version 7.2 19-Jun-07

Legend:
Removed from v.211  
changed lines
  Added in v.226

webmaster@exim.org
ViewVC Help
Powered by ViewVC 1.1.12