summaryrefslogtreecommitdiff
path: root/ext/pcre
Commit message (Collapse)AuthorAgeFilesLines
* Add additional preg_match test caseGraham Campbell2020-04-231-0/+35
| | | | | (cherry picked from commit a1a044dcc74379fafb2b63db5ab033aa062aada7 on author's explicit request)
* Fixed bug #79188Nikita Popov2020-02-052-18/+29
|
* Fix #78853: preg_match() may return integer > 1Christoph M. Becker2019-11-222-1/+13
| | | | | | | Commit 54ebebd[1] optimized the match loop, but for this case it has been overlooked, that we must only loop if we're doing global matching. [1] <http://git.php.net/?p=php-src.git;a=commit;h=54ebebd686255c5f124af718c966edb392782d4a>
* Fix php_pcre_mutex_free()Nikita Popov2019-11-071-2/+4
| | | | | | We should only set the mutex to NULL if we actually freed it. Due to missing braces non-main threads may currently set it to NULL first.
* Merge branch 'PHP-7.2' into PHP-7.3Nikita Popov2019-10-082-2/+11
|\
| * Add pcre_get_compiled_regex_cache_ex() with local_aware flagSergei Turchanov2019-10-082-2/+11
| | | | | | | | | | | | | | | | | | A new function `pcre_get_compiled_regex_cache_ex()` is introduced, which allows to compile regexp pattern using the "C" locale instead of a current locale. This will be needed to replace setlocale() usage in fileinfo, which is not thread-safe.
* | Backport fix for uaf during pcre jit fallbackNikita Popov2019-10-071-5/+5
| | | | | | | | | | Backports parts of https://vcs.pcre.org/pcre2?view=revision&revision=1175 fixing https://bugs.exim.org/show_bug.cgi?id=2453.
* | Improve diagnostic on PCRE JIT mmap failureNikita Popov2019-10-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | Print a more informative message that indicates that this is likely a permission issue, and also indicate that pcre.jit=0 can be used to work around it. Also automatically disable the JIT, so that this message is only shown once. See bug #78630.
* | Remove unstable test outputNikita Popov2019-09-181-2/+0
| | | | | | | | | | This may be printed in a different order, and we don't care about it anyway.
* | Fixed bug #78272Nikita Popov2019-09-182-1/+47
| | | | | | | | | | | | | | | | Use MAP_JIT only when running under hardened runtime, because MAP_JIT is incompatible with fork(). The check is based on https://github.com/mono/mono/commit/f879e35e3ed7496d819bd766deb8be6992d068ed.
* | Backport MAP_JIT fixes from PCRE2 10.33Nikita Popov2019-09-181-3/+43
| | | | | | | | | | | | | | | | This is intended to fix the primary issue from bug #77260. Prior to macOS 10.14 multiple MAP_JIT segments were not permitted, leading to mmap failures and corresponding "no more memory" errors on macOS 10.13.
* | Fix testStanislav Malyshev2019-08-251-1/+1
| | | | | | | | | | Not sure why offset changed... probably different PCRE version calculates them in different way.
* | Merge branch 'PHP-7.2' into PHP-7.3Stanislav Malyshev2019-08-251-0/+10
|\ \ | |/ | | | | | | * PHP-7.2: Fix #75457: heap-use-after-free in php7.0.25
| * Merge branch 'PHP-7.1' into PHP-7.2Stanislav Malyshev2019-08-251-0/+10
| |\ | | | | | | | | | | | | * PHP-7.1: Fix #75457: heap-use-after-free in php7.0.25
| | * Fix #75457: heap-use-after-free in php7.0.25Christoph M. Becker2019-08-252-1/+20
| | | | | | | | | | | | Backport <https://vcs.pcre.org/pcre?view=revision&revision=1638>.
| | * Sync leading and final newlines in *.phpt sectionsPeter Kokot2018-10-1526-33/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds missing newlines, trims multiple redundant final newlines into a single one, and trims redundant leading newlines in all *.phpt sections. According to POSIX, a line is a sequence of zero or more non-' <newline>' characters plus a terminating '<newline>' character. [1] Files should normally have at least one final newline character. C89 [2] and later standards [3] mention a final newline: "A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character." Although it is not mandatory for all files to have a final newline fixed, a more consistent and homogeneous approach brings less of commit differences issues and a better development experience in certain text editors and IDEs. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 [2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2 [3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
| | * Trim trailing whitespace in *.phptPeter Kokot2018-10-1430-50/+50
| | |
| | * Sync leading and final newlines in source code filesPeter Kokot2018-10-142-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds missing newlines, trims multiple redundant final newlines into a single one, and trims redundant leading newlines. According to POSIX, a line is a sequence of zero or more non-' <newline>' characters plus a terminating '<newline>' character. [1] Files should normally have at least one final newline character. C89 [2] and later standards [3] mention a final newline: "A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character." Although it is not mandatory for all files to have a final newline fixed, a more consistent and homogeneous approach brings less of commit differences issues and a better development experience in certain text editors and IDEs. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 [2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2 [3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
| | * Trim trailing whitespace in source code filesPeter Kokot2018-10-132-3/+3
| | |
| | * Convert CRLF line endings to LFPeter Kokot2018-10-132-69/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch simplifies line endings tracked in the Git repository and syncs them to all include the LF style instead of the CRLF files. Newline characters: - LF (\n) (*nix and Mac) - CRLF (\r\n) (Windows) - CR (\r) (old Mac, obsolete) To see which line endings are in the index and in the working copy the following command can be used: `git ls-files --eol` Git additionally provides `.gitattributes` file to specify if some files need to have specific line endings on all platforms (either CRLF or LF). Changed files shouldn't cause issues on modern Windows platforms because also Git can do output conversion is core.autocrlf=true is set on Windows and use CRLF newlines in all files in the working tree. Unless CRLF files are tracked specifically, Git by default tracks all files in the index using LF newlines.
| | * year++Xinchen Hui2018-01-022-2/+2
| | |
* | | ensure proper settings for testRemi Collet2019-08-201-0/+2
| | |
* | | Remove upgrade-pcre.php scriptChristoph M. Becker2019-08-011-137/+0
| | | | | | | | | | | | | | | This script has not been updated for PCRE2, and it's mostly useless anyway. Therefore we remove it altogether.
* | | Fix #78338: Array cross-border reading in PCREChristoph M. Becker2019-07-292-1/+11
| | | | | | | | | | | | We backport r1092 from pcre2.
* | | Fix bug #78197: PCRE2 version checkPeter Kokot2019-07-011-1/+1
| | | | | | | | | | | | | | | When external PCRE library version is of format ##.##-RC# the check failed.
* | | Merge branch 'PHP-7.2' into PHP-7.3Nikita Popov2019-06-171-1/+1
|\ \ \ | |/ /
| * | Accept null for preg_quote delimiter argumentNikita Popov2019-06-171-1/+1
| | | | | | | | | | | | Related to bug #78163.
* | | Merge branch 'PHP-7.2' into PHP-7.3Christoph M. Becker2019-03-312-0/+15
|\ \ \ | |/ / | | | | | | | | | * PHP-7.2: Fix #77827: preg_match does not ignore \r in regex flags
| * | Fix #77827: preg_match does not ignore \r in regex flagsChristoph M. Becker2019-03-312-0/+15
| | |
* | | ensure pcre.jit=1 for this testRemi Collet2019-03-221-0/+2
| | |
* | | Merge branch 'PHP-7.2' into PHP-7.3Remi Collet2019-03-221-0/+3
|\ \ \ | |/ / | | | | | | | | | * PHP-7.2: ensure pcre.jit=1 for these tests
| * | ensure pcre.jit=1 for these testsRemi Collet2019-03-221-0/+3
| | |
| * | Sync leading and final newlines in *.phpt sectionsPeter Kokot2018-10-1527-34/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds missing newlines, trims multiple redundant final newlines into a single one, and trims redundant leading newlines in all *.phpt sections. According to POSIX, a line is a sequence of zero or more non-' <newline>' characters plus a terminating '<newline>' character. [1] Files should normally have at least one final newline character. C89 [2] and later standards [3] mention a final newline: "A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character." Although it is not mandatory for all files to have a final newline fixed, a more consistent and homogeneous approach brings less of commit differences issues and a better development experience in certain text editors and IDEs. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 [2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2 [3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
| * | Trim trailing whitespace in *.phptPeter Kokot2018-10-1430-50/+50
| | |
| * | Sync leading and final newlines in source code filesPeter Kokot2018-10-142-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds missing newlines, trims multiple redundant final newlines into a single one, and trims redundant leading newlines. According to POSIX, a line is a sequence of zero or more non-' <newline>' characters plus a terminating '<newline>' character. [1] Files should normally have at least one final newline character. C89 [2] and later standards [3] mention a final newline: "A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character." Although it is not mandatory for all files to have a final newline fixed, a more consistent and homogeneous approach brings less of commit differences issues and a better development experience in certain text editors and IDEs. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 [2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2 [3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
| * | Trim trailing whitespace in source code filesPeter Kokot2018-10-132-3/+3
| | |
| * | Convert CRLF line endings to LFPeter Kokot2018-10-131-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch simplifies line endings tracked in the Git repository and syncs them to all include the LF style instead of the CRLF files. Newline characters: - LF (\n) (*nix and Mac) - CRLF (\r\n) (Windows) - CR (\r) (old Mac, obsolete) To see which line endings are in the index and in the working copy the following command can be used: `git ls-files --eol` Git additionally provides `.gitattributes` file to specify if some files need to have specific line endings on all platforms (either CRLF or LF). Changed files shouldn't cause issues on modern Windows platforms because also Git can do output conversion is core.autocrlf=true is set on Windows and use CRLF newlines in all files in the working tree. Unless CRLF files are tracked specifically, Git by default tracks all files in the index using LF newlines.
| * | Fixed possible incorrect "mark" usageDmitry Stogov2018-01-091-0/+5
| | |
| * | year++Xinchen Hui2018-01-022-2/+2
| | |
| * | Merge branch 'PHP-7.1' into PHP-7.2Anatol Belski2017-12-061-1/+3
| |\ \ | | |/ | | | | | | | | | * PHP-7.1: Fix yet one data race in PCRE
| | * Fix yet one data race in PCREAnatol Belski2017-12-061-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | PCRE 8.x initializes the pattern compiler on demand during the first pcre_study call. It could be worse, but since the compiled patterns are cached, the locking impact is minimal. PCRE 10.x always compiles the pattern and thread sanitizer doesn't complain about the compiler initialization, thus the newer PCRE version seems to be unafected.
* | | fix test for upcoming pcre2 10.33Remi Collet2019-03-192-2/+2
| | | | | | | | | | | | "group name ..." => "subpattern name ..."
* | | Fixed bug #76127Nikita Popov2019-03-194-11/+20
| | | | | | | | | | | | | | | Per documentation, and consistent with other preg functions, we should return false if an error occurred.
* | | Fixed bug #77338Nikita Popov2018-12-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set preg_options to 0 in php_pcre_get_compiled_regex(_ex). These options are intended to be passed to pcre2_match. However, we do not have any flags that actually need to be set during matching (all relevant flags are set during compilation), and the preg_flags value is used for PHP-specific flags instead. This parameter should be removed entirely in master to avoid confusion.
* | | Fixed bug #77193 Infinite loop in preg_replace_callbackAnatol Belski2018-12-012-8/+41
| | | | | | | | | | | | Don't return preallocated match data more than once in nested calls.
* | | Implement handling for JIT recognition when cross compilingAnatol Belski2018-11-051-2/+10
| | |
* | | Change the way JIT availability is checkedAnatol Belski2018-11-031-9/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pcre2_jit_compile_8 sysmbol is always available, even JIT might be not. If JIT is not enabled explicitly and is enabled in the PHP runtime, this will lead to a malfunction. This approach ensures JIT is indeed available on the given platform. For cross compilation this might get complicated, as it would require an explicit processor architecture and PCRE2 version check. Another solution for this case is to run pcre2_config at runtime. That however would require more condition checks that would impact architectures where JIT is available.
* | | Sync leading and final newlines in *.phpt sectionsPeter Kokot2018-10-1528-35/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds missing newlines, trims multiple redundant final newlines into a single one, and trims redundant leading newlines in all *.phpt sections. According to POSIX, a line is a sequence of zero or more non-' <newline>' characters plus a terminating '<newline>' character. [1] Files should normally have at least one final newline character. C89 [2] and later standards [3] mention a final newline: "A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character." Although it is not mandatory for all files to have a final newline fixed, a more consistent and homogeneous approach brings less of commit differences issues and a better development experience in certain text editors and IDEs. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 [2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2 [3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
* | | Trim trailing whitespace in *.phptPeter Kokot2018-10-1430-50/+50
| | |
* | | Sync leading and final newlines in source code filesPeter Kokot2018-10-143-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds missing newlines, trims multiple redundant final newlines into a single one, and trims redundant leading newlines. According to POSIX, a line is a sequence of zero or more non-' <newline>' characters plus a terminating '<newline>' character. [1] Files should normally have at least one final newline character. C89 [2] and later standards [3] mention a final newline: "A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character." Although it is not mandatory for all files to have a final newline fixed, a more consistent and homogeneous approach brings less of commit differences issues and a better development experience in certain text editors and IDEs. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 [2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2 [3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
View Lorry Controller Status