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

Diff of /code/trunk/ChangeLog

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

revision 1553 by ph10, Tue Apr 28 11:36:24 2015 UTC revision 1615 by ph10, Sun Nov 29 17:46:23 2015 UTC
# Line 1  Line 1 
1  ChangeLog for PCRE  ChangeLog for PCRE
2  ------------------  ------------------
3    
4    Note that the PCRE 8.xx series (PCRE1) is now in a bugfix-only state. All
5    development is happening in the PCRE2 10.xx series.
6    
7    Version 8.39 xx-xxxxxx-201x
8    ---------------------------
9    
10    1.  If PCRE_AUTO_CALLOUT was set on a pattern that had a (?# comment between
11        an item and its qualifier (for example, A(?#comment)?B) pcre_compile()
12        misbehaved. This bug was found by the LLVM fuzzer.
13    
14    2.  Similar to the above, if an isolated \E was present between an item and its
15        qualifier when PCRE_AUTO_CALLOUT was set, pcre_compile() misbehaved. This
16        bug was found by the LLVM fuzzer.
17    
18    3.  Further to 8.38/46, negated classes such as [^[:^ascii:]\d] were also not
19        working correctly in UCP mode.
20    
21    4.  The POSIX wrapper function regexec() crashed if the option REG_STARTEND
22        was set when the pmatch argument was NULL. It now returns REG_INVARG.
23    
24    5.  Allow for up to 32-bit numbers in the ordin() function in pcregrep.
25    
26    
27    Version 8.38 23-November-2015
28    -----------------------------
29    
30    1.  If a group that contained a recursive back reference also contained a
31        forward reference subroutine call followed by a non-forward-reference
32        subroutine call, for example /.((?2)(?R)\1)()/, pcre2_compile() failed to
33        compile correct code, leading to undefined behaviour or an internally
34        detected error. This bug was discovered by the LLVM fuzzer.
35    
36    2.  Quantification of certain items (e.g. atomic back references) could cause
37        incorrect code to be compiled when recursive forward references were
38        involved. For example, in this pattern: /(?1)()((((((\1++))\x85)+)|))/.
39        This bug was discovered by the LLVM fuzzer.
40    
41    3.  A repeated conditional group whose condition was a reference by name caused
42        a buffer overflow if there was more than one group with the given name.
43        This bug was discovered by the LLVM fuzzer.
44    
45    4.  A recursive back reference by name within a group that had the same name as
46        another group caused a buffer overflow. For example:
47        /(?J)(?'d'(?'d'\g{d}))/. This bug was discovered by the LLVM fuzzer.
48    
49    5.  A forward reference by name to a group whose number is the same as the
50        current group, for example in this pattern: /(?|(\k'Pm')|(?'Pm'))/, caused
51        a buffer overflow at compile time. This bug was discovered by the LLVM
52        fuzzer.
53    
54    6.  A lookbehind assertion within a set of mutually recursive subpatterns could
55        provoke a buffer overflow. This bug was discovered by the LLVM fuzzer.
56    
57    7.  Another buffer overflow bug involved duplicate named groups with a
58        reference between their definition, with a group that reset capture
59        numbers, for example: /(?J:(?|(?'R')(\k'R')|((?'R'))))/. This has been
60        fixed by always allowing for more memory, even if not needed. (A proper fix
61        is implemented in PCRE2, but it involves more refactoring.)
62    
63    8.  There was no check for integer overflow in subroutine calls such as (?123).
64    
65    9.  The table entry for \l in EBCDIC environments was incorrect, leading to its
66        being treated as a literal 'l' instead of causing an error.
67    
68    10. There was a buffer overflow if pcre_exec() was called with an ovector of
69        size 1. This bug was found by american fuzzy lop.
70    
71    11. If a non-capturing group containing a conditional group that could match
72        an empty string was repeated, it was not identified as matching an empty
73        string itself. For example: /^(?:(?(1)x|)+)+$()/.
74    
75    12. In an EBCDIC environment, pcretest was mishandling the escape sequences
76        \a and \e in test subject lines.
77    
78    13. In an EBCDIC environment, \a in a pattern was converted to the ASCII
79        instead of the EBCDIC value.
80    
81    14. The handling of \c in an EBCDIC environment has been revised so that it is
82        now compatible with the specification in Perl's perlebcdic page.
83    
84    15. The EBCDIC character 0x41 is a non-breaking space, equivalent to 0xa0 in
85        ASCII/Unicode. This has now been added to the list of characters that are
86        recognized as white space in EBCDIC.
87    
88    16. When PCRE was compiled without UCP support, the use of \p and \P gave an
89        error (correctly) when used outside a class, but did not give an error
90        within a class.
91    
92    17. \h within a class was incorrectly compiled in EBCDIC environments.
93    
94    18. A pattern with an unmatched closing parenthesis that contained a backward
95        assertion which itself contained a forward reference caused buffer
96        overflow. And example pattern is: /(?=di(?<=(?1))|(?=(.))))/.
97    
98    19. JIT should return with error when the compiled pattern requires more stack
99        space than the maximum.
100    
101    20. A possessively repeated conditional group that could match an empty string,
102        for example, /(?(R))*+/, was incorrectly compiled.
103    
104    21. Fix infinite recursion in the JIT compiler when certain patterns such as
105        /(?:|a|){100}x/ are analysed.
106    
107    22. Some patterns with character classes involving [: and \\ were incorrectly
108        compiled and could cause reading from uninitialized memory or an incorrect
109        error diagnosis.
110    
111    23. Pathological patterns containing many nested occurrences of [: caused
112        pcre_compile() to run for a very long time.
113    
114    24. A conditional group with only one branch has an implicit empty alternative
115        branch and must therefore be treated as potentially matching an empty
116        string.
117    
118    25. If (?R was followed by - or + incorrect behaviour happened instead of a
119        diagnostic.
120    
121    26. Arrange to give up on finding the minimum matching length for overly
122        complex patterns.
123    
124    27. Similar to (4) above: in a pattern with duplicated named groups and an
125        occurrence of (?| it is possible for an apparently non-recursive back
126        reference to become recursive if a later named group with the relevant
127        number is encountered. This could lead to a buffer overflow. Wen Guanxing
128        from Venustech ADLAB discovered this bug.
129    
130    28. If pcregrep was given the -q option with -c or -l, or when handling a
131        binary file, it incorrectly wrote output to stdout.
132    
133    29. The JIT compiler did not restore the control verb head in case of *THEN
134        control verbs. This issue was found by Karl Skomski with a custom LLVM
135        fuzzer.
136    
137    30. Error messages for syntax errors following \g and \k were giving inaccurate
138        offsets in the pattern.
139    
140    31. Added a check for integer overflow in conditions (?(<digits>) and
141        (?(R<digits>). This omission was discovered by Karl Skomski with the LLVM
142        fuzzer.
143    
144    32. Handling recursive references such as (?2) when the reference is to a group
145        later in the pattern uses code that is very hacked about and error-prone.
146        It has been re-written for PCRE2. Here in PCRE1, a check has been added to
147        give an internal error if it is obvious that compiling has gone wrong.
148    
149    33. The JIT compiler should not check repeats after a {0,1} repeat byte code.
150        This issue was found by Karl Skomski with a custom LLVM fuzzer.
151    
152    34. The JIT compiler should restore the control chain for empty possessive
153        repeats. This issue was found by Karl Skomski with a custom LLVM fuzzer.
154    
155    35. Match limit check added to JIT recursion. This issue was found by Karl
156        Skomski with a custom LLVM fuzzer.
157    
158    36. Yet another case similar to 27 above has been circumvented by an
159        unconditional allocation of extra memory. This issue is fixed "properly" in
160        PCRE2 by refactoring the way references are handled. Wen Guanxing
161        from Venustech ADLAB discovered this bug.
162    
163    37. Fix two assertion fails in JIT. These issues were found by Karl Skomski
164        with a custom LLVM fuzzer.
165    
166    38. Fixed a corner case of range optimization in JIT.
167    
168    39. An incorrect error "overran compiling workspace" was given if there were
169        exactly enough group forward references such that the last one extended
170        into the workspace safety margin. The next one would have expanded the
171        workspace. The test for overflow was not including the safety margin.
172    
173    40. A match limit issue is fixed in JIT which was found by Karl Skomski
174        with a custom LLVM fuzzer.
175    
176    41. Remove the use of /dev/null in testdata/testinput2, because it doesn't
177        work under Windows. (Why has it taken so long for anyone to notice?)
178    
179    42. In a character class such as [\W\p{Any}] where both a negative-type escape
180        ("not a word character") and a property escape were present, the property
181        escape was being ignored.
182    
183    43. Fix crash caused by very long (*MARK) or (*THEN) names.
184    
185    44. A sequence such as [[:punct:]b] that is, a POSIX character class followed
186        by a single ASCII character in a class item, was incorrectly compiled in
187        UCP mode. The POSIX class got lost, but only if the single character
188        followed it.
189    
190    45. [:punct:] in UCP mode was matching some characters in the range 128-255
191        that should not have been matched.
192    
193    46. If [:^ascii:] or [:^xdigit:] or [:^cntrl:] are present in a non-negated
194        class, all characters with code points greater than 255 are in the class.
195        When a Unicode property was also in the class (if PCRE_UCP is set, escapes
196        such as \w are turned into Unicode properties), wide characters were not
197        correctly handled, and could fail to match.
198    
199    
200  Version 8.37 28-April-2015  Version 8.37 28-April-2015
201  --------------------------  --------------------------
202    

Legend:
Removed from v.1553  
changed lines
  Added in v.1615

  ViewVC Help
Powered by ViewVC 1.1.5