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.
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.
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.
The $Id$ keywords were used in Subversion where they can be substituted
with filename, last revision number change, last changed date, and last
user who changed it.
In Git this functionality is different and can be done with Git attribute
ident. These need to be defined manually for each file in the
.gitattributes file and are afterwards replaced with 40-character
hexadecimal blob object name which is based only on the particular file
contents.
This patch simplifies handling of $Id$ keywords by removing them since
they are not used anymore.
If a locale other than C is active, character tables are saved into the
compile context. Every compiled pattern will have a pointer to the
character table, that was present in the context at the time of the
pattern compilation. Thus, the cache entries don't need to carry char
tables pointer, which reduces their size to 8 bytes on 64-bit. Instead,
the generated character tables are tracked in a separate HashTable. If a
character table was generated before, it'll be assigned to the compile
context when the locale changes. Otherwise a new char table will be
generated and cached.
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.
