Drop bogus ext/libxml dependency on ext/iconv (GH-16801)

There is no such dependency; only libxml2 depends on libiconv. So when
php_libxml.dll is built, it needs to be linked against li

Drop bogus ext/libxml dependency on ext/iconv (GH-16801)

There is no such dependency; only libxml2 depends on libiconv. So when
php_libxml.dll is built, it needs to be linked against libiconv, or,
when ext/iconv has been configured as static extension, against
php8.dll.

show more ...

Merge branch 'PHP-8.4'

* PHP-8.4:
Fix GH-16802: open_basedir bypass using curl extension

Merge branch 'PHP-8.3' into PHP-8.4

* PHP-8.3:
Fix GH-16802: open_basedir bypass using curl extension

Fix GH-16802: open_basedir bypass using curl extension

And fix a memleak while here.

Closes GH-16804.

Merge branch 'PHP-8.4'

* PHP-8.4:
Fix test expectation for different closure name in 8.4

Fix test expectation for different closure name in 8.4

Merge branch 'PHP-8.4'

* PHP-8.4:
Fix GH-16799: Assertion failure at Zend/zend_vm_execute.h:7469

Merge branch 'PHP-8.3' into PHP-8.4

* PHP-8.3:
Fix GH-16799: Assertion failure at Zend/zend_vm_execute.h:7469

Merge branch 'PHP-8.2' into PHP-8.3

* PHP-8.2:
Fix GH-16799: Assertion failure at Zend/zend_vm_execute.h:7469

Fix GH-16799: Assertion failure at Zend/zend_vm_execute.h:7469

zend_is_callable_ex() can unfortunately emit a deprecation, and then
a user error handler can throw an exception. This caus

Fix GH-16799: Assertion failure at Zend/zend_vm_execute.h:7469

zend_is_callable_ex() can unfortunately emit a deprecation, and then
a user error handler can throw an exception. This causes an assert
failure at ZEND_VM_NEXT_OPCODE(). We fix this by checking if there's an
exception after zend_is_callable_ex().

Closes GH-16803.

show more ...

Merge branch 'PHP-8.4'

* PHP-8.4:
Adapt ext/intl tests for ICU 75.1 and 76.1

Merge branch 'PHP-8.3' into PHP-8.4

* PHP-8.3:
Adapt ext/intl tests for ICU 75.1 and 76.1

Merge branch 'PHP-8.2' into PHP-8.3

* PHP-8.2:
Adapt ext/intl tests for ICU 75.1 and 76.1

Adapt ext/intl tests for ICU 75.1 and 76.1

Closes GH-16788.

Merge branch 'PHP-8.4'

Fix GH-16812: UAF on readline_info() after readline_write_history() call.

close GH-16813

Merge branch 'PHP-8.3' into PHP-8.4

* PHP-8.3:
Stick with icu4c 74.2 on macOS CI for PHP-8.1

Merge branch 'PHP-8.4'

* PHP-8.4:
Fix GH-16770: Tracing JIT type mismatch when returning UNDEF

Merge branch 'PHP-8.3' into PHP-8.4

* PHP-8.3:
Fix GH-16770: Tracing JIT type mismatch when returning UNDEF

Merge branch 'PHP-8.2' into PHP-8.3

* PHP-8.2:
Fix GH-16770: Tracing JIT type mismatch when returning UNDEF

Fix GH-16770: Tracing JIT type mismatch when returning UNDEF

When returning an UNDEF value, it actually becomes NULL.
The following code took this into account:
https://github.com/ph

Fix GH-16770: Tracing JIT type mismatch when returning UNDEF

When returning an UNDEF value, it actually becomes NULL.
The following code took this into account:
https://github.com/php/php-src/blob/28344e0445bc2abae8dc5f1376aa0ff350e6d66d/ext/opcache/jit/zend_jit_trace.c#L2196-L2199

But the stack does not update the type to NULL, causing a mismatch.

Closes GH-16784.

Co-authored-by: Dmitry Stogov <dmitry@zend.com>

show more ...

Merge branch 'PHP-8.4'

* PHP-8.4:
Fix i386 release build warning

Fix i386 release build warning

Closes GH-16730

UPGRADING: Fix `CURLOPT_TCP_KEEPCNT` entry

Simplify WBMP imagecreatefromstring() detection (GH-16782)

According to the WBMP specification[1], the first field (type) of a
WBMP is a multi-byte integer, but only type `0` is supporte

Simplify WBMP imagecreatefromstring() detection (GH-16782)

According to the WBMP specification[1], the first field (type) of a
WBMP is a multi-byte integer, but only type `0` is supported. Thus
there is no need to read a multi-byte integer. The second field (fix
header) is a single byte; reading a multi-byte integer is not really
wrong, since the fix header field is laid out in a way which allows it
to be treated as such, but the check whether the MBI is greater than
or equal to zero is pretty useless, because negative values could only
be returned if overflow occurs (MBIs are unsigned).

So the only useful assumption we can make is that the first byte is
zero; we let `gdImageCreateFromWBMPCtx()` figure out the rest.

[1] <https://www.wapforum.org/what/technical/SPEC-WAESpec-19990524.pdf> section 6

show more ...