The test failure is not particularly related to Travis, but rather is
caused by the GD font file to only be suitable for platforms where
`int` stores 32bit values in little endian byte order. This platform
dependence is documented in the source code[1]. Thus we fix the skip
condition and skip reason accordingly.
An alternative would be to dynamically create the font file just before
running the test, but that appears to be overkill.
[1] <d59691c02f/ext/gd/gd.c (L545-L556)>
Closes GH-14922.
Besides demonstrating the new behavior, this test also ensures that the
bundled and external libgd now behave the same. It has to be noted,
though, that we only test one of the five code paths.
Closes GH-14945.
According to the docs (https://www.php.net/manual/en/function.imagecreatefromwebp.php and https://www.php.net/manual/en/function.imagewebp.php), `false` should be returned on errors (similar to other functions of the `gd` extension), but actually all errors result in a `Fatal Error`. It doesn't look normal when trying to read an empty file or a file in the wrong format causes the program to stop. The problem seems to be related to a mega-patch that replaced `zend_error` with `zend_error_noreturn` almost everywhere. My patch fixes this behavior by switching from `zend_error_noerror` to `gd_error` (i.e. to `E_WARNING` level). All necessary memory cleanup is already in the code (as it was before the "zend_error_noreturn" patch).
Close GH-13774
The LICENSE file of libmagic had been inadvertently removed when the
lib had been upgraded to 5.43. So we add the file `COPYING` from that
release[1], and rename it to `LICENSE`.
[1] <https://github.com/file/file/releases/tag/FILE5_43>
Closes GH-14917.
The create_obj handler of InternalIterator is overwritten, but not the
clone_obj handler. This is not allowed.
In PHP 8.2 this didn't cause a segfault because the standard object
handler was used for the clone instead of the internal handler.
So then it allocates and frees the object using the standard object handlers.
In 8.3 however, the object is created using the standard object handler and
freed using the custom handler, resulting in the buffer overflow.
Even though bisect points to 1e1ea4f this only reveals the bug.
Closes GH-14882.
When dealing with a file, we must free the contents if the function
fails. While here, also fix the error message because previously it
sounded like the filename was too long while in fact the file itself
is too large.
Closes GH-14862.
`spl_object_storage_attach_handle` creates an entry already, but only
fills it in at the end with `spl_object_storage_create_element` which
allocates memory. In this case the allocation fails and we're left with
a NULL slot. Doing the allocation first isn't an option because we want
to check whether the slot is occupied before allocating memory.
The simplest solution is to set the entry to NULL and check for a NULL
pointer upon destruction.
Closes GH-14849.
libxml2 2.13 makes changes to how the parsing state is set, update our
code accordingly. In particular, it started reporting entities within
attributes, while it should only report entities inside text nodes.
Closes GH-14837.
* PHP-8.2:
NEWS for compatibility in XML
Stop setting parse options directly
Stop relying on lastError directly
Stop relying on the sax2 flag directly
Port XML_GetCurrentByteIndex to public APIs
* PHP-8.2:
NEWS for GH-14814
ext/standard/tests: strings/wordwrap_memory_limit_32bit.phpt has two outputs
ext/standard/tests: 32bit wordwrap tests aren't just for Windows
It turns out that on a 32-bit system, this test can produce either the
"usual" expected output from the 64-bit test, OR the 32-bit-only
integer overflow message. We copy the dual expected outputs from
chunk_split_variation1_32bit.phpt to handle both cases.
This fixes an earlier commit that split the two tests based only on
the size of an int (32-bit versus 64-bit). The CI reveals that, at
least on a debug/zts build, the "64-bit" memory limit error (and not
the integer overflow error) is still produced.
The test in strings/wordwrap_memory_limit.phpt has a counterpart in
strings/wordwrap_memory_limit_win32.phpt. The two are conditional on
both the OS name and the size of an int (32- versus 64-bits).
A Gentoo Linux user has however reported that the 64-bit test fails on
a 32-bit system, with precisely the error message that the "win32"
test is expecting. I don't have any 32-bit hardware to test myself,
but I think it's reasonable to conclude that the OS name is not an
essential part of the test: it's simply 32- versus 64-bit.
This commit drops the conditionals for the OS name. Now one test will
be run on 32-bit systems, and the other on 64-bit systems, regardless
of the OS name.
Bug: https://bugs.gentoo.org/935382
In strings/chunk_split_variation1_32bit.phpt, we have a test that is
expected to fail on x32 with a possible integer overflow error. The
message reports the exact number of bytes -- a number big enough to
overflow an int on x32 -- stemming from a memory allocation in
chunk_split().
This number appears unpredictable, and is not the point of the test.
We replace it with %d to make the test independent of the allocation
details.
