changelog

以便Apache与其他服务进行整合 Mod_JK安装

        -Wl,--out-implib,.libs/@[e-mail].a \

    to look similar to other lines, but I have no way of telling whether this
    is the right thing to do, as I do not use Windows. No doubt I'll get told
    if it's wrong...


Version 4.3 21-May-03
---------------------

1. Two instances of @WIN_PREFIX@ omitted from the Windows targets in the
   Makefile.

2. Some refactoring to improve the quality of the code:

   (i)   The utf8_table... variables are now declared "const".

   (ii)  The code for \cx, which used the "case flipping" table to upper case
         lower case letters, now just substracts 32. This is ASCII-specific,
         but the whole concept of \cx is ASCII-specific, so it seems
         reasonable.

   (iii) PCRE was using its character types table to recognize decimal and
         hexadecimal digits in the pattern. This is silly, because it handles
         only 0-9, a-f, and A-F, but the character types table is locale-
         specific, which means strange things might happen. A private
         table is now used for this - though it costs 256 bytes, a table is
         much faster than multiple explicit tests. Of course, the standard
         character types table is still used for matching digits in subject
         strings against \d.

   (iv)  Strictly, the identifier ESC_t is reserved by POSIX (all identifiers
         ending in _t are). So I've renamed it as ESC_tee.

3. The first argument for regexec() in the POSIX wrapper should have been
   defined as "const".

4. Changed pcretest to use malloc() for its buffers so that they can be
   Electric Fenced for debugging.

5. There were several places in the code where, in UTF-8 mode, PCRE would try
   to read one or more bytes before the start of the subject string. Often this
   had no effect on PCRE's behaviour, but in some circumstances it could
   provoke a segmentation fault.

6. A lookbehind at the start of a pattern in UTF-8 mode could also cause PCRE
   to try to read one or more bytes before the start of the subject string.

7. A lookbehind in a pattern matched in non-UTF-8 mode on a PCRE compiled with
   UTF-8 support could misbehave in various ways if the subject string
   contained bytes with the 0x80 bit set and the 0x40 bit unset in a lookbehind
   area. (PCRE was not checking for the UTF-8 mode flag, and trying to move
   back over UTF-8 characters.)


Version 4.2 14-Apr-03
---------------------

1. Typo "#if SUPPORT_UTF8" instead of "#ifdef SUPPORT_UTF8" fixed.

2. Changes to the building process, supplied by Ronald Landheer-Cieslak
     [ON_WINDOWS]: new variable, "#" on non-Windows platforms
     [NOT_ON_WINDOWS]: new variable, "#" on Windows platforms
     [WIN_PREFIX]: new variable, "cyg" for Cygwin
     * Makefile.in: use autoconf substitution for OBJEXT, EXEEXT, BUILD_OBJEXT
       and BUILD_EXEEXT
     Note: automatic setting of the BUILD variables is not yet working
     set CPPFLAGS and BUILD_CPPFLAGS (but don't use yet) - should be used at
       compile-time but not at link-time
     [LINK]: use for linking executables only
     make different versions for Windows and non-Windows
     [LINKLIB]: new variable, copy of UNIX-style LINK, used for linking
       libraries
     [LINK_FOR_BUILD]: new variable
     [OBJEXT]: use throughout
     [EXEEXT]: use throughout
     <winshared>: new target
     <wininstall>: new target
     <dftables.o>: use native compiler
     <dftables>: use native linker
     <install>: handle Windows platform correctly
     <clean>: ditto
     <check>: ditto
     copy DLL to top builddir before testing

   As part of these changes, -no-undefined was removed again. This was reported
   to give trouble on HP-UX 11.0, so getting rid of it seems like a good idea
   in any case.

3. Some tidies to get rid of compiler warnings:

   . In the match_data structure, match_limit was an unsigned long int, whereas
     match_call_count was an int. I've made them both unsigned long ints.

   . In pcretest the fact that a const uschar * doesn't automatically cast to
     a void * provoked a warning.

   . Turning on some more compiler warnings threw up some "shadow" variables
     and a few more missing casts.

4. If PCRE was complied with UTF-8 support, but called without the PCRE_UTF8
   option, a class that contained a single character with a value between 128
   and 255 (e.g. /[\xFF]/) caused PCRE to crash.

5. If PCRE was compiled with UTF-8 support, but called without the PCRE_UTF8
   option, a class that contained several characters, but with at least one
   whose value was between 128 and 255 caused PCRE to crash.


Version 4.1 12-Mar-03
---------------------

1. Compiling with gcc -pedantic found a couple of places where casts were
needed, and a string in dftables.c that was longer than standard compilers are
required to support.

2. Compiling with Sun's compiler found a few more places where the code could
be tidied up in order to avoid warnings.

3. The variables for cross-compiling were called HOST_CC and HOST_CFLAGS; the
first of these names is deprecated in the latest Autoconf in favour of the name
CC_FOR_BUILD, because "host" is typically used to mean the system on which the
compiled code will be run. I can't find a reference for HOST_CFLAGS, but by
analogy I have changed it to CFLAGS_FOR_BUILD.

4. Added -no-undefined to the linking command in the Makefile, because this is
apparently helpful for Windows. To make it work, also added "-L. -lpcre" to the
linking step for the pcreposix library.

5. PCRE was failing to diagnose the case of two named groups with the same
name.

6. A problem with one of PCRE's optimizations was discovered. PCRE remembers a
literal character that is needed in the subject for a match, and scans along to
ensure that it is present before embarking on the full matching process. This
saves time in cases of nested unlimited repeats that are never going to match.
Problem: the scan can take a lot of time if the subject is very long (e.g.
megabytes), thus penalizing straightforward matches. It is now done only if the
amount of subject to be scanned is less than 1000 bytes.

7. A lesser problem with the same optimization is that it was recording the
first character of an anchored pattern as "needed", thus provoking a search
right along the subject, even when the first match of the pattern was going to
fail. The "needed" character is now not set for anchored patterns, unless it
follows something in the pattern that is of non-fixed length. Thus, it still
fulfils its original purpose of finding quick non-matches in cases of nested
unlimited repeats, but isn't used for simple anchored patterns such as /^abc/.


Version 4.0 17-Feb-03
---------------------

1. If a comment in an extended regex that started immediately after a meta-item
extended to the end of string, PCRE compiled incorrect data. This could lead to
all kinds of weird effects. Example: /#/ was bad; /()#/ was bad; /a#/ was not.

2. Moved to autoconf 2.53 and libtool 1.4.2.

3. Perl 5.8 no longer needs "use utf8" for doing UTF-8 things. Consequently,
the special perltest8 script is no longer needed - all the tests can be run
from a single perltest script.

4. From 5.004, Perl has not included the VT character (0x0b) in the set defined
by \s. It has now been removed in PCRE. This means it isn't recognized as
whitespace in /x regexes too, which is the same as Perl. Note that the POSIX
class [:space:] *does* include VT, thereby creating a mess.

5. Added the class [:blank:] (a GNU extension from Perl 5.8) to match only
space and tab.

6. Perl 5.005 was a long time ago. It's time to amalgamate the tests that use
its new features into the main test script, reducing the number of scripts.

7. Perl 5.8 has changed the meaning of patterns like /a(?i)b/. Earlier versions
were backward compatible, and made the (?i) apply to the whole pattern, as if
/i were given. Now it behaves more logically, and applies the option setting
only to what follows. PCRE has been changed to follow suit. However, if it
finds options settings right at the start of the pattern, it extracts them into
the global options, as before. Thus, they show up in the info data.

8. Added support for the \Q...\E escape sequence. Characters in between are
treated as literals. This is slightly different from Perl in that $ and @ are
also handled as literals inside the quotes. In Perl, they will cause variable
interpolation. Note the following examples:

    Pattern            PCRE matches      Perl matches

    \Qabc$xyz\E        abc$xyz           abc followed by the contents of $xyz
    \Qabc\$xyz\E       abc\$xyz          abc\$xyz
    \Qabc\E\$\Qxyz\E   abc$xyz           abc$xyz

For compatibility with Perl, \Q...\E sequences are recognized inside character
classes as well as outside them.

9. Re-organized 3 code statements in pcretest to avoid "overflow in
floating-point constant arithmetic" warnings from a Microsoft compiler. Added a
(size_t) cast to one statement in pcretest and one in pcreposix to avoid
signed/unsigned warnings.

10. SunOS4 doesn't have strtoul(). This was used only for unpicking the -o
option for pcretest, so I've replaced it by a simple function that does just
that job.

11. pcregrep was ending with code 0 instead of 2 for the commands "pcregrep" or
"pcregrep -".

12. Added "possessive quantifiers" ?+, *+, ++, and {,}+ which come from Sun's
Java package. This provides some syntactic sugar for simple cases of what my
documentation calls "once-only subpatterns". A pattern such as x*+ is the same
as (?>x*). In other words, if what is inside (?>...) is just a single repeated
item, you can use this simplified notation. Note that only makes sense with
greedy quantifiers. Consequently, the use of the possessive quantifier forces
greediness, whatever the setting of the PCRE_UNGREEDY option.

13. A change of greediness default within a pattern was not taking effect at
the current level for patterns like /(b+(?U)a+)/. It did apply to parenthesized
subpatterns that followed. Patterns like /b+(?U)a+/ worked because the option
was abstracted outside.

14. PCRE now supports the \G assertion. It is true when the current matching
position is at the start point of the match. This differs from \A when the
starting offset is non-zero. Used with the /g option of pcretest (or similar
code), it works in the same way as it does for Perl's /g option. If all
alternatives of a regex begin with \G, the expression is anchored to the start
match position, and the "anchored" flag is set in the compiled expression.

15. Some bugs concerning the handling of certain option changes within patterns
have been fixed. These applied to options other than (?ims). For example,
"a(?x: b c )d" did not match "XabcdY" but did match "Xa b c dY". It should have
been the other way round. Some of this was related to change 7 above.

16. PCRE now gives errors for /[.x.]/ and /[=x=]/ as unsupported POSIX
features, as Perl does. Previously, PCRE gave the warnings only for /[[.x.]]/
and /[[=x=]]/. PCRE now also gives an error for /[:name:]/ because it supports
POSIX classes only within a class (e.g. /[[:alpha:]]/).

17. Added support for Perl's \C escape. This matches one byte, even in UTF8
mode. Unlike ".", it always matches newline, whatever the setting of
PCRE_DOTALL. However, PCRE does not permit \C to appear in lookbehind
assertions. Perl allows it, but it doesn't (in general) work because it can't
calculate the length of the lookbehind. At least, that's the case for Perl
5.8.0 - I've been told they are going to document that it doesn't work in
future.

18. Added an error diagnosis for escapes that PCRE does not support: these are
\L, \l, \N, \P, \p, \U, \u, and \X.

19. Although correctly diagnosing a missing ']' in a character class, PCRE was
reading past the end of the pattern in cases such as /[abcd/.

20. PCRE was getting more memory than necessary for patterns with classes that
contained both POSIX named classes and other characters, e.g. /[[:space:]abc/.

21. Added some code, conditional on #ifdef VPCOMPAT, to make life easier for
compiling PCRE for use with Virtual Pascal.

22. Small fix to the Makefile to make it work properly if the build is done
outside the source tree.

23. Added a new extension: a condition to go with recursion. If a conditional
subpattern starts with (?(R) the "true" branch is used if recursion has
happened, whereas the "false" branch is used only at the top level.

24. When there was a very long string of literal characters (over 255 bytes
without UTF support, over 250 bytes with UTF support), the computation of how
much memory was required could be incorrect, leading to segfaults or other
strange effects.

25. PCRE was incorrectly assuming anchoring (either to start of subject or to
start of line for a non-DOTALL pattern) when a pattern started with (.*) and
there was a subsequent back reference to those brackets. This meant that, for
example, /(.*)\d+\1/ failed to match "abc123bc". Unfortunately, it isn't
possible to check for precisely this case. All we can do is abandon the
optimization if .* occurs inside capturing brackets when there are any back
references whatsoever. (See below for a better fix that came later.)

26. The handling of the optimization for finding the first character of a
non-anchored pattern, and for finding a character that is required later in the
match were failing in some cases. This didn't break the matching; it just
failed to optimize when it could. The way this is done has been re-implemented.

27. Fixed typo in error message for invalid (?R item (it said "(?p").

28. Added a new feature that provides some of the functionality that Perl
provides with (?{...}). The facility is termed a "callout". The way it is done
in PCRE is for the caller to provide an optional function, by setting
pcre_callout to its entry point. Like pcre_malloc and pcre_free, this is a