/[pcre]/code/trunk/ChangeLog

Diff of /code/trunk/ChangeLog

Parent Directory | Revision Log | View Patch Patch

-revision 484 by ph10,
Mon Jan  4 17:11:54 2010 UTC
+revision 642 by ph10,
Thu Jul 28 18:59:40 2011 UTC
 Line 1
  ChangeLog for PCRE
  ------------------
- Version 8.01 11-Dec-09
+ Version 8.13 30-Apr-2011
- ----------------------
+ ------------------------
+.  The Unicode data tables have been updated to Unicode 6.0.0.
+.  Two minor typos in pcre_internal.h have been fixed.
+.  Added #include <string.h> to pcre_scanner_unittest.cc, pcrecpp.cc, and
+     pcrecpp_unittest.cc. They are needed for strcmp(), memset(), and strchr()
+     in some environments (e.g. Solaris 10/SPARC using Sun Studio 12U2).
+.  There were a number of related bugs in the code for matching backrefences
+     caselessly in UTF-8 mode when codes for the characters concerned were
+     different numbers of bytes. For example, U+023A and U+2C65 are an upper
+     and lower case pair, using 2 and 3 bytes, respectively. The main bugs were:
+     (a) A reference to 3 copies of a 2-byte code matched only 2 of a 3-byte
+     code. (b) A reference to 2 copies of a 3-byte code would not match 2 of a
+-byte code at the end of the subject (it thought there wasn't enough data
+     left).
+.  Comprehensive information about what went wrong is now returned by
+     pcre_exec() and pcre_dfa_exec() when the UTF-8 string check fails, as long
+     as the output vector has at least 2 elements. The offset of the start of
+     the failing character and a reason code are placed in the vector.
+.  When the UTF-8 string check fails for pcre_compile(), the offset that is
+     now returned is for the first byte of the failing character, instead of the
+     last byte inspected. This is an incompatible change, but I hope it is small
+     enough not to be a problem. It makes the returned offset consistent with
+     pcre_exec() and pcre_dfa_exec().
+.  pcretest now gives a text phrase as well as the error number when
+     pcre_exec() or pcre_dfa_exec() fails; if the error is a UTF-8 check
+     failure, the offset and reason code are output.
+.  When \R was used with a maximizing quantifier it failed to skip backwards
+     over a \r\n pair if the subsequent match failed. Instead, it just skipped
+     back over a single character (\n). This seems wrong (because it treated the
+     two characters as a single entity when going forwards), conflicts with the
+     documentation that \R is equivalent to (?>\r\n|\n|...etc), and makes the
+     behaviour of \R* different to (\R)*, which also seems wrong. The behaviour
+     has been changed.
+.  Some internal refactoring has changed the processing so that the handling
+     of the PCRE_CASELESS and PCRE_MULTILINE options is done entirely at compile
+     time (the PCRE_DOTALL option was changed this way some time ago: version
+.7 change 16). This has made it possible to abolish the OP_OPT op code,
+     which was always a bit of a fudge. It also means that there is one less
+     argument for the match() function, which reduces its stack requirements
+     slightly. This change also fixes an incompatibility with Perl: the pattern
+     (?i:([^b]))(?1) should not match "ab", but previously PCRE gave a match.
+. More internal refactoring has drastically reduced the number of recursive
+     calls to match() for possessively repeated groups such as (abc)++ when
+     using pcre_exec().
+. While implementing 10, a number of bugs in the handling of groups were
+     discovered and fixed:
+     (?<=(a)+) was not diagnosed as invalid (non-fixed-length lookbehind).
+     (a|)*(?1) gave a compile-time internal error.
+     ((a|)+)+  did not notice that the outer group could match an empty string.
+     (^a|^)+   was not marked as anchored.
+     (.*a|.*)+ was not marked as matching at start or after a newline.
+. Yet more internal refactoring has removed another argument from the match()
+     function. Special calls to this function are now indicated by setting a
+     value in a variable in the "match data" data block.
+. Be more explicit in pcre_study() instead of relying on "default" for
+     opcodes that mean there is no starting character; this means that when new
+     ones are added and accidentally left out of pcre_study(), testing should
+     pick them up.
+. The -s option of pcretest has been documented for ages as being an old
+     synonym of -m (show memory usage). I have changed it to mean "force study
+     for every regex", that is, assume /S for every regex. This is similar to -i
+     and -d etc. It's slightly incompatible, but I'm hoping nobody is still
+     using it. It makes it easier to run collections of tests with and without
+     study enabled, and thereby test pcre_study() more easily. All the standard
+     tests are now run with and without -s (but some patterns can be marked as
+     "never study" - see 20 below).
+. When (*ACCEPT) was used in a subpattern that was called recursively, the
+     restoration of the capturing data to the outer values was not happening
+     correctly.
+. If a recursively called subpattern ended with (*ACCEPT) and matched an
+     empty string, and PCRE_NOTEMPTY was set, pcre_exec() thought the whole
+     pattern had matched an empty string, and so incorrectly returned a no
+     match.
+. There was optimizing code for the last branch of non-capturing parentheses,
+     and also for the obeyed branch of a conditional subexpression, which used
+     tail recursion to cut down on stack usage. Unfortunately, not that there is
+     the possibility of (*THEN) occurring in these branches, tail recursion is
+     no longer possible because the return has to be checked for (*THEN). These
+     two optimizations have therefore been removed.
+. If a pattern containing \R was studied, it was assumed that \R always
+     matched two bytes, thus causing the minimum subject length to be
+     incorrectly computed because \R can also match just one byte.
+. If a pattern containing (*ACCEPT) was studied, the minimum subject length
+     was incorrectly computed.
+. If /S is present twice on a test pattern in pcretest input, it *disables*
+     studying, thereby overriding the use of -s on the command line. This is
+     necessary for one or two tests to keep the output identical in both cases.
+. When (*ACCEPT) was used in an assertion that matched an empty string and
+     PCRE_NOTEMPTY was set, PCRE applied the non-empty test to the assertion.
+. When an atomic group that contained a capturing parenthesis was
+     successfully matched, but the branch in which it appeared failed, the
+     capturing was not being forgotten if a higher numbered group was later
+     captured. For example, /(?>(a))b|(a)c/ when matching "ac" set capturing
+     group 1 to "a", when in fact it should be unset. This applied to multi-
+     branched capturing and non-capturing groups, repeated or not, and also to
+     positive assertions (capturing in negative assertions is not well defined
+     in PCRE) and also to nested atomic groups.
+. Add the ++ qualifier feature to pcretest, to show the remainder of the
+     subject after a captured substring (to make it easier to tell which of a
+     number of identical substrings has been captured).
+. The way atomic groups are processed by pcre_exec() has been changed so that
+     if they are repeated, backtracking one repetition now resets captured
+     values correctly. For example, if ((?>(a+)b)+aabab) is matched against
+     "aaaabaaabaabab" the value of captured group 2 is now correctly recorded as
+     "aaa". Previously, it would have been "a". As part of this code
+     refactoring, the way recursive calls are handled has also been changed.
+. If an assertion condition captured any substrings, they were not passed
+     back unless some other capturing happened later. For example, if
+     (?(?=(a))a) was matched against "a", no capturing was returned.
+. When studying a pattern that contained subroutine calls or assertions,
+     the code for finding the minimum length of a possible match was handling
+     direct recursions such as (xxx(?1)|yyy) but not mutual recursions (where
+     group 1 called group 2 while simultaneously a separate group 2 called group
+). A stack overflow occurred in this case. I have fixed this by limiting
+     the recursion depth to 10.
+. Updated RunTest.bat in the distribution to the version supplied by Tom
+     Fortmann. This supports explicit test numbers on the command line, and has
+     argument validation and error reporting.
+. An instance of \X with an unlimited repeat could fail if at any point the
+     first character it looked at was a mark character.
+. Some minor code refactoring concerning Unicode properties and scripts
+     should reduce the stack requirement of match() slightly.
+. Added the '=' option to pcretest to check the setting of unused capturing
+     slots at the end of the pattern, which are documented as being -1, but are
+     not included in the return count.
+. If \k was not followed by a braced, angle-bracketed, or quoted name, PCRE
+     compiled something random. Now it gives a compile-time error (as does
+     Perl).
+. A *MARK encountered during the processing of a positive assertion is now
+     recorded and passed back (compatible with Perl).
+. If --only-matching or --colour was set on a pcregrep call whose pattern
+     had alternative anchored branches, the search for a second match in a line
+     was done as if at the line start. Thus, for example, /^01|^02/ incorrectly
+     matched the line "0102" twice. The same bug affected patterns that started
+     with a backwards assertion. For example /\b01|\b02/ also matched "0102"
+     twice.
+. Previously, PCRE did not allow quantification of assertions. However, Perl
+     does, and because of capturing effects, quantifying parenthesized
+     assertions may at times be useful. Quantifiers are now allowed for
+     parenthesized assertions.
+. A minor code tidy in pcre_compile() when checking options for \R usage.
+. \g was being checked for fancy things in a character class, when it should
+     just be a literal "g".
+. PCRE was rejecting [:a[:digit:]] whereas Perl was not. It seems that the
+     appearance of a nested POSIX class supersedes an apparent external class.
+     For example, [:a[:digit:]b:] matches "a", "b", ":", or a digit. Also,
+     unescaped square brackets may also appear as part of class names. For
+     example, [:a[:abc]b:] gives unknown class "[:abc]b:]". PCRE now behaves
+     more like Perl.
+. PCRE was giving an error for \N with a braced quantifier such as {1,} (this
+     was because it thought it was \N{name}, which is not supported).
+. Add minix to OS list not supporting the -S option in pcretest.
+. PCRE tries to detect cases of infinite recursion at compile time, but it
+     cannot analyze patterns in sufficient detail to catch mutual recursions
+     such as ((?1))((?2)). There is now a runtime test that gives an error if a
+     subgroup is called recursively as a subpattern for a second time at the
+     same position in the subject string. In previous releases this might have
+     been caught by the recursion limit, or it might have run out of stack.
+. A pattern such as /(?(R)a+|(?R)b)/ is quite safe, as the recursion can
+     happen only once. PCRE was, however incorrectly giving a compile time error
+     "recursive call could loop indefinitely" because it cannot analyze the
+     pattern in sufficient detail. The compile time test no longer happens when
+     PCRE is compiling a conditional subpattern, but actual runaway loops are
+     now caught at runtime (see 39 above).
+ Version 8.12 15-Jan-2011
+ ------------------------
+.  Fixed some typos in the markup of the man pages, and wrote a script that
+     checks for such things as part of the documentation building process.
+.  On a big-endian 64-bit system, pcregrep did not correctly process the
+     --match-limit and --recursion-limit options (added for 8.11). In
+     particular, this made one of the standard tests fail. (The integer value
+     went into the wrong half of a long int.)
+.  If the --colour option was given to pcregrep with -v (invert match), it
+     did strange things, either producing crazy output, or crashing. It should,
+     of course, ignore a request for colour when reporting lines that do not
+     match.
+.  Another pcregrep bug caused similar problems if --colour was specified with
+     -M (multiline) and the pattern match finished with a line ending.
+.  In pcregrep, when a pattern that ended with a literal newline sequence was
+     matched in multiline mode, the following line was shown as part of the
+     match. This seems wrong, so I have changed it.
+.  Another pcregrep bug in multiline mode, when --colour was specified, caused
+     the check for further matches in the same line (so they could be coloured)
+     to overrun the end of the current line. If another match was found, it was
+     incorrectly shown (and then shown again when found in the next line).
+.  If pcregrep was compiled under Windows, there was a reference to the
+     function pcregrep_exit() before it was defined. I am assuming this was
+     the cause of the "error C2371: 'pcregrep_exit' : redefinition;" that was
+     reported by a user. I've moved the definition above the reference.
+ Version 8.11 10-Dec-2010
+ ------------------------
+.  (*THEN) was not working properly if there were untried alternatives prior
+     to it in the current branch. For example, in ((a|b)(*THEN)(*F)|c..) it
+     backtracked to try for "b" instead of moving to the next alternative branch
+     at the same level (in this case, to look for "c"). The Perl documentation
+     is clear that when (*THEN) is backtracked onto, it goes to the "next
+     alternative in the innermost enclosing group".
+.  (*COMMIT) was not overriding (*THEN), as it does in Perl. In a pattern
+     such as   (A(*COMMIT)B(*THEN)C|D)  any failure after matching A should
+     result in overall failure. Similarly, (*COMMIT) now overrides (*PRUNE) and
+     (*SKIP), (*SKIP) overrides (*PRUNE) and (*THEN), and (*PRUNE) overrides
+     (*THEN).
+.  If \s appeared in a character class, it removed the VT character from
+     the class, even if it had been included by some previous item, for example
+     in [\x00-\xff\s]. (This was a bug related to the fact that VT is not part
+     of \s, but is part of the POSIX "space" class.)
+.  A partial match never returns an empty string (because you can always
+     match an empty string at the end of the subject); however the checking for
+     an empty string was starting at the "start of match" point. This has been
+     changed to the "earliest inspected character" point, because the returned
+     data for a partial match starts at this character. This means that, for
+     example, /(?<=abc)def/ gives a partial match for the subject "abc"
+     (previously it gave "no match").
+.  Changes have been made to the way PCRE_PARTIAL_HARD affects the matching
+     of $, \z, \Z, \b, and \B. If the match point is at the end of the string,
+     previously a full match would be given. However, setting PCRE_PARTIAL_HARD
+     has an implication that the given string is incomplete (because a partial
+     match is preferred over a full match). For this reason, these items now
+     give a partial match in this situation. [Aside: previously, the one case
+     /t\b/ matched against "cat" with PCRE_PARTIAL_HARD set did return a partial
+     match rather than a full match, which was wrong by the old rules, but is
+     now correct.]
+.  There was a bug in the handling of #-introduced comments, recognized when
+     PCRE_EXTENDED is set, when PCRE_NEWLINE_ANY and PCRE_UTF8 were also set.
+     If a UTF-8 multi-byte character included the byte 0x85 (e.g. +U0445, whose
+     UTF-8 encoding is 0xd1,0x85), this was misinterpreted as a newline when
+     scanning for the end of the comment. (*Character* 0x85 is an "any" newline,
+     but *byte* 0x85 is not, in UTF-8 mode). This bug was present in several
+     places in pcre_compile().
+.  Related to (6) above, when pcre_compile() was skipping #-introduced
+     comments when looking ahead for named forward references to subpatterns,
+     the only newline sequence it recognized was NL. It now handles newlines
+     according to the set newline convention.
+.  SunOS4 doesn't have strerror() or strtoul(); pcregrep dealt with the
+     former, but used strtoul(), whereas pcretest avoided strtoul() but did not
+     cater for a lack of strerror(). These oversights have been fixed.
+.  Added --match-limit and --recursion-limit to pcregrep.
+. Added two casts needed to build with Visual Studio when NO_RECURSE is set.
+. When the -o option was used, pcregrep was setting a return code of 1, even
+     when matches were found, and --line-buffered was not being honoured.
+. Added an optional parentheses number to the -o and --only-matching options
+     of pcregrep.
+. Imitating Perl's /g action for multiple matches is tricky when the pattern
+     can match an empty string. The code to do it in pcretest and pcredemo
+     needed fixing:
+     (a) When the newline convention was "crlf", pcretest got it wrong, skipping
+         only one byte after an empty string match just before CRLF (this case
+         just got forgotten; "any" and "anycrlf" were OK).
+     (b) The pcretest code also had a bug, causing it to loop forever in UTF-8
+         mode when an empty string match preceded an ASCII character followed by
+         a non-ASCII character. (The code for advancing by one character rather
+         than one byte was nonsense.)
+     (c) The pcredemo.c sample program did not have any code at all to handle
+         the cases when CRLF is a valid newline sequence.
+. Neither pcre_exec() nor pcre_dfa_exec() was checking that the value given
+     as a starting offset was within the subject string. There is now a new
+     error, PCRE_ERROR_BADOFFSET, which is returned if the starting offset is
+     negative or greater than the length of the string. In order to test this,
+     pcretest is extended to allow the setting of negative starting offsets.
+. In both pcre_exec() and pcre_dfa_exec() the code for checking that the
+     starting offset points to the beginning of a UTF-8 character was
+     unnecessarily clumsy. I tidied it up.
+. Added PCRE_ERROR_SHORTUTF8 to make it possible to distinguish between a
+     bad UTF-8 sequence and one that is incomplete when using PCRE_PARTIAL_HARD.
+. Nobody had reported that the --include_dir option, which was added in
+     release 7.7 should have been called --include-dir (hyphen, not underscore)
+     for compatibility with GNU grep. I have changed it to --include-dir, but
+     left --include_dir as an undocumented synonym, and the same for
+     --exclude-dir, though that is not available in GNU grep, at least as of
+     release 2.5.4.
+. At a user's suggestion, the macros GETCHAR and friends (which pick up UTF-8
+     characters from a string of bytes) have been redefined so as not to use
+     loops, in order to improve performance in some environments. At the same
+     time, I abstracted some of the common code into auxiliary macros to save
+     repetition (this should not affect the compiled code).
+. If \c was followed by a multibyte UTF-8 character, bad things happened. A
+     compile-time error is now given if \c is not followed by an ASCII
+     character, that is, a byte less than 128. (In EBCDIC mode, the code is
+     different, and any byte value is allowed.)
+. Recognize (*NO_START_OPT) at the start of a pattern to set the PCRE_NO_
+     START_OPTIMIZE option, which is now allowed at compile time - but just
+     passed through to pcre_exec() or pcre_dfa_exec(). This makes it available
+     to pcregrep and other applications that have no direct access to PCRE
+     options. The new /Y option in pcretest sets this option when calling
+     pcre_compile().
+. Change 18 of release 8.01 broke the use of named subpatterns for recursive
+     back references. Groups containing recursive back references were forced to
+     be atomic by that change, but in the case of named groups, the amount of
+     memory required was incorrectly computed, leading to "Failed: internal
+     error: code overflow". This has been fixed.
+. Some patches to pcre_stringpiece.h, pcre_stringpiece_unittest.cc, and
+     pcretest.c, to avoid build problems in some Borland environments.
+ Version 8.10 25-Jun-2010
+ ------------------------
+.  Added support for (*MARK:ARG) and for ARG additions to PRUNE, SKIP, and
+     THEN.
+.  (*ACCEPT) was not working when inside an atomic group.
+.  Inside a character class, \B is treated as a literal by default, but
+     faulted if PCRE_EXTRA is set. This mimics Perl's behaviour (the -w option
+     causes the error). The code is unchanged, but I tidied the documentation.
+.  Inside a character class, PCRE always treated \R and \X as literals,
+     whereas Perl faults them if its -w option is set. I have changed PCRE so
+     that it faults them when PCRE_EXTRA is set.
+.  Added support for \N, which always matches any character other than
+     newline. (It is the same as "." when PCRE_DOTALL is not set.)
+.  When compiling pcregrep with newer versions of gcc which may have
+     FORTIFY_SOURCE set, several warnings "ignoring return value of 'fwrite',
+     declared with attribute warn_unused_result" were given. Just casting the
+     result to (void) does not stop the warnings; a more elaborate fudge is
+     needed. I've used a macro to implement this.
+.  Minor change to pcretest.c to avoid a compiler warning.
+.  Added four artifical Unicode properties to help with an option to make
+     \s etc use properties (see next item). The new properties are: Xan
+     (alphanumeric), Xsp (Perl space), Xps (POSIX space), and Xwd (word).
+.  Added PCRE_UCP to make \b, \d, \s, \w, and certain POSIX character classes
+     use Unicode properties. (*UCP) at the start of a pattern can be used to set
+     this option. Modified pcretest to add /W to test this facility. Added
+     REG_UCP to make it available via the POSIX interface.
+. Added --line-buffered to pcregrep.
+. In UTF-8 mode, if a pattern that was compiled with PCRE_CASELESS was
+     studied, and the match started with a letter with a code point greater than
+whose first byte was different to the first byte of the other case of
+     the letter, the other case of this starting letter was not recognized
+     (#976).
+. If a pattern that was studied started with a repeated Unicode property
+     test, for example, \p{Nd}+, there was the theoretical possibility of
+     setting up an incorrect bitmap of starting bytes, but fortunately it could
+     not have actually happened in practice until change 8 above was made (it
+     added property types that matched character-matching opcodes).
+. pcre_study() now recognizes \h, \v, and \R when constructing a bit map of
+     possible starting bytes for non-anchored patterns.
+. Extended the "auto-possessify" feature of pcre_compile(). It now recognizes
+     \R, and also a number of cases that involve Unicode properties, both
+     explicit and implicit when PCRE_UCP is set.
+. If a repeated Unicode property match (e.g. \p{Lu}*) was used with non-UTF-8
+     input, it could crash or give wrong results if characters with values
+     greater than 0xc0 were present in the subject string. (Detail: it assumed
+     UTF-8 input when processing these items.)
+. Added a lot of (int) casts to avoid compiler warnings in systems where
+     size_t is 64-bit (#991).
+. Added a check for running out of memory when PCRE is compiled with
+     --disable-stack-for-recursion (#990).
+. If the last data line in a file for pcretest does not have a newline on
+     the end, a newline was missing in the output.
+. The default pcre_chartables.c file recognizes only ASCII characters (values
+     less than 128) in its various bitmaps. However, there is a facility for
+     generating tables according to the current locale when PCRE is compiled. It
+     turns out that in some environments, 0x85 and 0xa0, which are Unicode space
+     characters, are recognized by isspace() and therefore were getting set in
+     these tables, and indeed these tables seem to approximate to ISO 8859. This
+     caused a problem in UTF-8 mode when pcre_study() was used to create a list
+     of bytes that can start a match. For \s, it was including 0x85 and 0xa0,
+     which of course cannot start UTF-8 characters. I have changed the code so
+     that only real ASCII characters (less than 128) and the correct starting
+     bytes for UTF-8 encodings are set for characters greater than 127 when in
+     UTF-8 mode. (When PCRE_UCP is set - see 9 above - the code is different
+     altogether.)
+. Added the /T option to pcretest so as to be able to run tests with non-
+     standard character tables, thus making it possible to include the tests
+     used for 19 above in the standard set of tests.
+. A pattern such as (?&t)(?#()(?(DEFINE)(?<t>a)) which has a forward
+     reference to a subpattern the other side of a comment that contains an
+     opening parenthesis caused either an internal compiling error, or a
+     reference to the wrong subpattern.
+ Version 8.02 19-Mar-2010
+ ------------------------
+.  The Unicode data tables have been updated to Unicode 5.2.0.
+.  Added the option --libs-cpp to pcre-config, but only when C++ support is
+     configured.
+.  Updated the licensing terms in the pcregexp.pas file, as agreed with the
+     original author of that file, following a query about its status.
+.  On systems that do not have stdint.h (e.g. Solaris), check for and include
+     inttypes.h instead. This fixes a bug that was introduced by change 8.01/8.
+.  A pattern such as (?&t)*+(?(DEFINE)(?<t>.)) which has a possessive
+     quantifier applied to a forward-referencing subroutine call, could compile
+     incorrect code or give the error "internal error: previously-checked
+     referenced subpattern not found".
+.  Both MS Visual Studio and Symbian OS have problems with initializing
+     variables to point to external functions. For these systems, therefore,
+     pcre_malloc etc. are now initialized to local functions that call the
+     relevant global functions.
+.  There were two entries missing in the vectors called coptable and poptable
+     in pcre_dfa_exec.c. This could lead to memory accesses outsize the vectors.
+     I've fixed the data, and added a kludgy way of testing at compile time that
+     the lengths are correct (equal to the number of opcodes).
+.  Following on from 7, I added a similar kludge to check the length of the
+     eint vector in pcreposix.c.
+.  Error texts for pcre_compile() are held as one long string to avoid too
+     much relocation at load time. To find a text, the string is searched,
+     counting zeros. There was no check for running off the end of the string,
+     which could happen if a new error number was added without updating the
+     string.
+. \K gave a compile-time error if it appeared in a lookbehind assersion.
+. \K was not working if it appeared in an atomic group or in a group that
+     was called as a "subroutine", or in an assertion. Perl 5.11 documents that
+     \K is "not well defined" if used in an assertion. PCRE now accepts it if
+     the assertion is positive, but not if it is negative.
+. Change 11 fortuitously reduced the size of the stack frame used in the
+     "match()" function of pcre_exec.c by one pointer. Forthcoming
+     implementation of support for (*MARK) will need an extra pointer on the
+     stack; I have reserved it now, so that the stack frame size does not
+     decrease.
+. A pattern such as (?P<L1>(?P<L2>0)|(?P>L2)(?P>L1)) in which the only other
+     item in branch that calls a recursion is a subroutine call - as in the
+     second branch in the above example - was incorrectly given the compile-
+     time error "recursive call could loop indefinitely" because pcre_compile()
+     was not correctly checking the subroutine for matching a non-empty string.
+. The checks for overrunning compiling workspace could trigger after an
+     overrun had occurred. This is a "should never occur" error, but it can be
+     triggered by pathological patterns such as hundreds of nested parentheses.
+     The checks now trigger 100 bytes before the end of the workspace.
+. Fix typo in configure.ac: "srtoq" should be "strtoq".
+ Version 8.01 19-Jan-2010
+ ------------------------
 .  If a pattern contained a conditional subpattern with only one branch (in
-     particular, this includes all (DEFINE) patterns), a call to pcre_study()
+     particular, this includes all (*DEFINE) patterns), a call to pcre_study()
      computed the wrong minimum data length (which is of course zero for such
-     subpatterns).
+     subpatterns). This could cause incorrect "no match" results.
 .  For patterns such as (?i)a(?-i)b|c where an option setting at the start of
      the pattern is reset in the first branch, pcre_compile() failed with
-Line 61 
 Version 8.01 11-Dec-09
+Line 594 
 Version 8.01 11-Dec-09
      custom one, because of the following reported problem in Windows:
        - libbz2 uses the Pascal calling convention (WINAPI) for the functions
-         under Win32.
+           under Win32.
        - The standard autoconf AC_CHECK_LIB fails to include "bzlib.h",
-         therefore missing the function definition.
+           therefore missing the function definition.
        - The compiler thus generates a "C" signature for the test function.
        - The linker fails to find the "C" function.
        - PCRE fails to configure if asked to do so against libbz2.
 . When running libtoolize from libtool-2.2.6b as part of autogen.sh, these
      messages were output:
        Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
        rerunning libtoolize, to keep the correct libtool macros in-tree.
        Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
      I have done both of these things.
 . Although pcre_dfa_exec() does not use nearly as much stack as pcre_exec()
      most of the time, it *can* run out if it is given a pattern that contains a
      runaway infinite recursion. I updated the discussion in the pcrestack man
      page.
 . Now that we have gone to the x.xx style of version numbers, the minor
      version may start with zero. Using 08 or 09 is a bad idea because users
      might check the value of PCRE_MINOR in their code, and 08 or 09 may be
      interpreted as invalid octal numbers. I've updated the previous comment in
      configure.ac, and also added a check that gives an error if 08 or 09 are
      used.
 . Change 8.00/11 was not quite complete: code had been accidentally omitted,
      causing partial matching to fail when the end of the subject matched \W
      in a UTF-8 pattern where \W was quantified with a minimum of 3.
 . There were some discrepancies between the declarations in pcre_internal.h
      of _pcre_is_newline(), _pcre_was_newline(), and _pcre_valid_utf8() and
      their definitions. The declarations used "const uschar *" and the
      definitions used USPTR. Even though USPTR is normally defined as "const
      unsigned char *" (and uschar is typedeffed as "unsigned char"), it was
      reported that: "This difference in casting confuses some C++ compilers, for
      example, SunCC recognizes above declarations as different functions and
      generates broken code for hbpcre." I have changed the declarations to use
      USPTR.
 . GNU libtool is named differently on some systems. The autogen.sh script now
      tries several variants such as glibtoolize (MacOSX) and libtoolize1x
      (FreeBSD).
+. Applied Craig's patch that fixes an HP aCC compile error in pcre 8.00
+     (strtoXX undefined when compiling pcrecpp.cc). The patch contains this
+     comment: "Figure out how to create a longlong from a string: strtoll and
+     equivalent. It's not enough to call AC_CHECK_FUNCS: hpux has a strtoll, for
+     instance, but it only takes 2 args instead of 3!"
+. A subtle bug concerned with back references has been fixed by a change of
+     specification, with a corresponding code fix. A pattern such as
+     ^(xa|=?\1a)+$ which contains a back reference inside the group to which it
+     refers, was giving matches when it shouldn't. For example, xa=xaaa would
+     match that pattern. Interestingly, Perl (at least up to 5.11.3) has the
+     same bug. Such groups have to be quantified to be useful, or contained
+     inside another quantified group. (If there's no repetition, the reference
+     can never match.) The problem arises because, having left the group and
+     moved on to the rest of the pattern, a later failure that backtracks into
+     the group uses the captured value from the final iteration of the group
+     rather than the correct earlier one. I have fixed this in PCRE by forcing
+     any group that contains a reference to itself to be an atomic group; that
+     is, there cannot be any backtracking into it once it has completed. This is
+     similar to recursive and subroutine calls.
  Version 8.00 19-Oct-09

 Legend:



Removed from v.484
 


changed lines


 
Added in v.642
 Legend:



Removed from v.484
 


changed lines


 
Added in v.642
-Removed from v.484
+Added in v.642

	ViewVC Help
Powered by ViewVC 1.1.5