📄 changelog
字号:
21. The pcre-exec() function can now cope with patterns that were compiled on hosts of opposite endianness, with this restriction: As for any compiled expression that is saved and used later, the tables pointer field cannot be preserved; the extra_data field in the arguments to pcre_exec() should be used to pass in a tables address if a value other than the default internal tables were used at compile time.22. Calling pcre_exec() with a negative value of the "ovecsize" parameter is now diagnosed as an error. Previously, most of the time, a negative number would have been treated as zero, but if in addition "ovector" was passed as NULL, a crash could occur.23. Updated the files ltmain.sh, config.sub, config.guess, and aclocal.m4 with new versions from the libtool 1.5 distribution (the last one is a copy of a file called libtool.m4). This seems to have fixed the need to patch "configure" to support Darwin 1.3 (which I used to do). However, I still had to patch ltmain.sh to ensure that ${SED} is set (it isn't on my workstation).24. Changed the PCRE licence to be the more standard "BSD" licence.Version 4.5 01-Dec-03--------------------- 1. There has been some re-arrangement of the code for the match() function so that it can be compiled in a version that does not call itself recursively. Instead, it keeps those local variables that need separate instances for each "recursion" in a frame on the heap, and gets/frees frames whenever it needs to "recurse". Keeping track of where control must go is done by means of setjmp/longjmp. The whole thing is implemented by a set of macros that hide most of the details from the main code, and operates only if NO_RECURSE is defined while compiling pcre.c. If PCRE is built using the "configure" mechanism, "--disable-stack-for-recursion" turns on this way of operating. To make it easier for callers to provide specially tailored get/free functions for this usage, two new functions, pcre_stack_malloc, and pcre_stack_free, are used. They are always called in strict stacking order, and the size of block requested is always the same. The PCRE_CONFIG_STACKRECURSE info parameter can be used to find out whether PCRE has been compiled to use the stack or the heap for recursion. The -C option of pcretest uses this to show which version is compiled. A new data escape \S, is added to pcretest; it causes the amounts of store obtained and freed by both kinds of malloc/free at match time to be added to the output. 2. Changed the locale test to use "fr_FR" instead of "fr" because that's what's available on my current Linux desktop machine. 3. When matching a UTF-8 string, the test for a valid string at the start has been extended. If start_offset is not zero, PCRE now checks that it points to a byte that is the start of a UTF-8 character. If not, it returns PCRE_ERROR_BADUTF8_OFFSET (-11). Note: the whole string is still checked; this is necessary because there may be backward assertions in the pattern. When matching the same subject several times, it may save resources to use PCRE_NO_UTF8_CHECK on all but the first call if the string is long. 4. The code for checking the validity of UTF-8 strings has been tightened so that it rejects (a) strings containing 0xfe or 0xff bytes and (b) strings containing "overlong sequences". 5. Fixed a bug (appearing twice) that I could not find any way of exploiting! I had written "if ((digitab[*p++] && chtab_digit) == 0)" where the "&&" should have been "&", but it just so happened that all the cases this let through by mistake were picked up later in the function. 6. I had used a variable called "isblank" - this is a C99 function, causing some compilers to warn. To avoid this, I renamed it (as "blankclass"). 7. Cosmetic: (a) only output another newline at the end of pcretest if it is prompting; (b) run "./pcretest /dev/null" at the start of the test script so the version is shown; (c) stop "make test" echoing "./RunTest". 8. Added patches from David Burgess to enable PCRE to run on EBCDIC systems. 9. The prototype for memmove() for systems that don't have it was using size_t, but the inclusion of the header that defines size_t was later. I've moved the #includes for the C headers earlier to avoid this.10. Added some adjustments to the code to make it easier to compiler on certain special systems: (a) Some "const" qualifiers were missing. (b) Added the macro EXPORT before all exported functions; by default this is defined to be empty. (c) Changed the dftables auxiliary program (that builds chartables.c) so that it reads its output file name as an argument instead of writing to the standard output and assuming this can be redirected.11. In UTF-8 mode, if a recursive reference (e.g. (?1)) followed a character class containing characters with values greater than 255, PCRE compilation went into a loop.12. A recursive reference to a subpattern that was within another subpattern that had a minimum quantifier of zero caused PCRE to crash. For example, (x(y(?2))z)? provoked this bug with a subject that got as far as the recursion. If the recursively-called subpattern itself had a zero repeat, that was OK.13. In pcretest, the buffer for reading a data line was set at 30K, but the buffer into which it was copied (for escape processing) was still set at 1024, so long lines caused crashes.14. A pattern such as /[ab]{1,3}+/ failed to compile, giving the error "internal error: code overflow...". This applied to any character class that was followed by a possessive quantifier.15. Modified the Makefile to add libpcre.la as a prerequisite for libpcreposix.la because I was told this is needed for a parallel build to work.16. If a pattern that contained .* following optional items at the start was studied, the wrong optimizing data was generated, leading to matching errors. For example, studying /[ab]*.*c/ concluded, erroneously, that any matching string must start with a or b or c. The correct conclusion for this pattern is that a match can start with any character.Version 4.4 13-Aug-03--------------------- 1. In UTF-8 mode, a character class containing characters with values between 127 and 255 was not handled correctly if the compiled pattern was studied. In fixing this, I have also improved the studying algorithm for such classes (slightly). 2. Three internal functions had redundant arguments passed to them. Removal might give a very teeny performance improvement. 3. Documentation bug: the value of the capture_top field in a callout is *one more than* the number of the hightest numbered captured substring. 4. The Makefile linked pcretest and pcregrep with -lpcre, which could result in incorrectly linking with a previously installed version. They now link explicitly with libpcre.la. 5. configure.in no longer needs to recognize Cygwin specially. 6. A problem in pcre.in for Windows platforms is fixed. 7. If a pattern was successfully studied, and the -d (or /D) flag was given to pcretest, it used to include the size of the study block as part of its output. Unfortunately, the structure contains a field that has a different size on different hardware architectures. This meant that the tests that showed this size failed. As the block is currently always of a fixed size, this information isn't actually particularly useful in pcretest output, so I have just removed it. 8. Three pre-processor statements accidentally did not start in column 1. Sadly, there are *still* compilers around that complain, even though standard C has not required this for well over a decade. Sigh. 9. In pcretest, the code for checking callouts passed small integers in the callout_data field, which is a void * field. However, some picky compilers complained about the casts involved for this on 64-bit systems. Now pcretest passes the address of the small integer instead, which should get rid of the warnings.10. By default, when in UTF-8 mode, PCRE now checks for valid UTF-8 strings at both compile and run time, and gives an error if an invalid UTF-8 sequence is found. There is a option for disabling this check in cases where the string is known to be correct and/or the maximum performance is wanted.11. In response to a bug report, I changed one line in Makefile.in from -Wl,--out-implib,.libs/lib@WIN_PREFIX@pcreposix.dll.a \ to -Wl,--out-implib,.libs/@WIN_PREFIX@libpcreposix.dll.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 m
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -