The following commit introduces a cross-compilation failure:
93c728b77c
"Try to control ZEND_MM_ALIGNED_SIZE type"
br-arm-full/build/php-7.4.2/Zend/zend_alloc.h:30:38:
error: missing binary operator before token "8"
^
br-arm-full/build/php-7.4.2/ext/opcache/ZendAccelerator.c:1380:7:
note: in expansion of macro ‘ZEND_MM_ALIGNMENT’
Closes GH-5128.
The SplFixedArray API treats all elements as NULL, even if they
have not been explicitly initialized. Rather than initializing
to UNDEF an treating that specially in various circumstances,
directly initialize elements to NULL.
This also fixes an assertion failure in the attached test case.
The fix for bug #49634 solved a double-free by copying the node with
`xmlDocCopyNodeList()`, but the copied node is later freed by calling
`xmlFreeNode()` instead of `xmlFreeNodeList()`, thus leaking memory.
However, there is no need to treat the node as node list, i.e. to copy
also the node's siblings; just creating a recursive copy of the node
with `xmlDocCopyNode()` is sufficient, while that also avoids the leak.
While it would be desireable to actually support unserialization of
NumberFormatter instances, at least we should not allow serialization
for now.
We also remove some doubtful tests, which have been added[1] claiming
that they would crash the intl extension, but apparently no fix has
been applied, and the test cases have not been marked as XFAIL.
[1] <http://git.php.net/?p=php-src.git;a=commit;h=ed793b2a3f857fd49c0c1b036062140da5b3e674>
I replaced it with a multiplication overflow check in
18599f9c52. However, we need both,
because the code for restoring the number can't handle numbers
with many leading zeros right now and I don't feel like teaching it.
These are enabled on non Windows systems as of zip 1.16.0 with libzip
>= 1.0.0. Since Windows builds use at least libzip 1.4.0, we also
enable these methods there.
This is going to cause a segfault if reused in the next request.
To illustrate the issue, run these two scripts in sequence with
the built-in server:
// script1.php
mb_ereg_search_init('foobar');
mb_ereg_search('foo');
// script2.php
var_dump(mb_ereg_search_init("foobar"));
var_dump(mb_ereg_search_pos());
This has been introduced by 84b0d0faba.
Besides it causes runtime issues on POWER5 (and presumably later), the
implementation would expect this array to consist on 32-bit integers.
Don't mix strlen() and ZSTR_LEN(). If the encoding contains a
NULL byte, this will overflow the buffer.
NULL bytes will still make this behave oddly because the consuming
code will cut off the string there, but let's address that in master...
