We backport the respective upstream fix[1] to our bundled pcre2lib plus
the follow-up fix[2] for a functional regression.
[1] <dc5f966635>
[2] <e7af7efaa1>
Closes GH-7573.
Excerpt from the release news:
Version 10.37 26-May-2021
-------------------------
A few more bug fixes and tidies. The only change of real note is the removal of
the actual POSIX names regcomp etc. from the POSIX wrapper library because
these have caused issues for some applications (see 10.33 #2 below).
Version 10.36 04-December-2020
------------------------------
Again, mainly bug fixes and tidies. The only enhancements are the addition of
GNU grep's -m (aka --max-count) option to pcre2grep, and also unifying the
handling of substitution strings for both -O and callouts in pcre2grep, with
the addition of $x{...} and $o{...} to allow for characters whose code points
are greater than 255 in Unicode mode.
NOTE: there is an outstanding issue with JIT support for MacOS on arm64
hardware. For details, please see Bugzilla issue #2618.
Signed-off-by: Anatol Belski <ab@php.net>
When compiling with "-Wall -Werror" gcc emits two errors:
../src/pcre2_jit_neon_inc.h:211:8: error: ‘cmp1b’ is used uninitialized in this function [-Werror=uninitialized]
211 | data = fast_forward_char_pair_compare(compare1_type, data, cmp1a, cmp1b);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/pcre2_jit_neon_inc.h:212:9: error: ‘cmp2b’ is used uninitialized in this function [-Werror=uninitialized]
212 | data2 = fast_forward_char_pair_compare(compare2_type, data2, cmp2a, cmp2b);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The compiler emits the error message before inlining.
Because the warning is based on an intra-procedural data
flow analysis, the compiler does not see that cmp1b and
cmp2b are not used when they are not initialized.
Here is the code of that function, cmp2 is only used
when ctype is compare_match2 or compare_match1i,
and not when ctype is compare_match1:
static inline vect_t fast_forward_char_pair_compare(compare_type ctype, vect_t dst, vect_t cmp1, vect_t cmp2)
{
if (ctype == compare_match2)
{
vect_t tmp = dst;
dst = VCEQQ(dst, cmp1);
tmp = VCEQQ(tmp, cmp2);
dst = VORRQ(dst, tmp);
return dst;
}
if (ctype == compare_match1i)
dst = VORRQ(dst, cmp2);
dst = VCEQQ(dst, cmp1);
return dst;
}
The patch inlines by hand the case of compare_match1 such that the
code avoids referring to cmp1b and cmp2b.
Tested on aarch64-linux with `make check`.
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.
Autoconf defines PACKAGE_* symbols:
- PACKAGE_NAME
- PACKAGE_VERSION
- PACKAGE_TARNAME
- PACKAGE_STRING
- PACKAGE_BUGREPORT
- PACKAGE_URL
and appends them to the generated config.h.in files. With AC_INIT change
via afd52f9d99 where package version, URL,
bug report location and similar meta data are defined, these
preprocessor macros are then non empty strings in the generated
configuration header file. When using phpize, PHP shares the config
files in extensions, warnings of redefined macros appear, such as:
- `warning: 'PACKAGE_NAME' macro redefined`
This patch now disables these non utilized symbols in the generated
config header files.
Better practice would be to include only API specific headers where
needed but this would require even more refactorings. Some extensions
such as pcre, pgsql, and pdo_pgsql solve this issue by undefining some
of these symbols before including the library configuration headers in
the code also. Because these symbols can be defined by any library which
uses Autotools.
Additionally, the unused PACKAGE_* symbols were cleaned for the bundled
libmbfl library and with this patch not needed undef code removed.
