This is addon to the GH-13727 bug fix. When configuring the build with:
./configure CFLAGS=-Werror=strict-prototypes
libtool check for parsing nm command would fail:
checking command to parse /usr/bin/nm -B output from cc object... failed
Upstream libtool has this specific check already fixed. Note that this
works only with Autoconf version 2.72 and later and is preparation for
future compilers that might have this error enabled by default.
This is a backport of commit 03f15534a1 to
PHP-8.2 due to GH-14002 and fixes the PHP_CXX_COMPILE_STDCXX check in
ext/intl whether the specified C++ standard is mandatory or optional.
The `dnl` (Discard to Next Line) M4 macro in this combination of `m4_if`
macros and arguments isn't properly replaced and a literal `dnl` string
is appended in the configure script. The `[]dnl` works ok.
When step_callback fails, agg_context->val is passed dtor, but agg_context->val
is also used in final_callback regardless of the success/failure of step_callback,
so should not call dtor.
closes#14004fixes#13998
* PHP-8.2:
[ci skip] NEWS
fix: zend-max-execution-timers with negative or high timeout value (#13942)
Use return value of getpwuid_r(), not errno (#13969)
In the test cases, the compiler bails out due to a fatal error.
The data structures used by the compiler will contain stale values.
In particular, for the test case CG(loop_var_stack) will contain data.
The next compilation will incorrectly use elements from the previous
stack.
To solve this, we reset part of the compiler data structures.
We don't do a full re-initialization via init_compiler() because that will
also reset streams and resources.
Closes GH-13938.
This test performs a few checks to ensure that "not too much" memory
is used while fileinfo is detecting encodings. It is however platform
specific, and memory usage varies across hosts and as libmagic changes.
Recently a Gentoo user reported a failure in this test at,
https://bugs.gentoo.org/927461
on a big-endian PPC64 machine with output,
---- EXPECTED OUTPUT
131072 => ok
262144 => ok
524288 => ok
1048576 => ok
2097152 => ok
4194304 => ok
8388608 => ok
16777216 => ok
---- ACTUAL OUTPUT
131072 => 10092544
262144 => 10092544
524288 => 12189696
1048576 => 12189696
2097152 => 14352384
4194304 => 18612224
8388608 => 24903680
16777216 => 37486592
---- FAILED
Those numbers are with 8.3.4 and therefore missing commit b7c5813c
which also raises the limits. Checking the "actual" numbers above
against the current values, we see that the limit for 524288 would
need to be bumped to 12189696 to allow this test to pass. Since that
seems reasonable, that's what this commit does.
Closes GH-13795
Closes GH-13940
