All other code caters to dereferencing array elements, except the
unserialize handler. This causes references to be present in the fixed
array even though this seems not intentional as reference assign is
otherwise impossible.
On 8.5+ this causes an assertion failure. On 8.3+ this causes references
to be present where they shouldn't be.
Closes GH-20616.
The string added had uninitialized memory due to
php_read_stream_all_chunks() not moving the buffer position, resulting
in the same data always being overwritten instead of new data being
added to the end of the buffer.
Closes GH-20592.
The issue is specific to SLES15.
Arguably this should be reported to them as it seems to me they meddled
with the oniguruma source code.
The definition in oniguruma.h on that platform looks like this (same as upstream):
```c
ONIG_EXTERN
int onig_error_code_to_str PV_((OnigUChar* s, int err_code, ...));
```
Where `PV_` is defined as (differs):
```c
#ifndef PV_
#ifdef HAVE_STDARG_PROTOTYPES
# define PV_(args) args
#else
# define PV_(args) ()
#endif
#endif
```
So that means that `HAVE_STDARG_PROTOTYPES` is unset.
This can be set if we define `HAVE_STDARG_H`,
which we can do because PHP requires at least C99 in which the header
is always available.
We could also use an autoconf check, but this isn't really necessary as
it will always succeed.
While this fixed the last deprecation in ext/libxml, it's not a full
fix: The full fix would be to move to the context-specific APIs to
override the behaviour. However, that requires API/ABI incompatible
changes so that can't be done on a stable branch.
Closes GH-20525.
The return type has been zip_int64_t since 2009, so we shouldn't
truncate to an int because the user may have requested a size that won't
fit in an int.
Closes GH-20509.
Symfony 8.1 and 8.0 now require PHP 8.4. Use 7.4 for PHP 8.3 and 8.2 builds. PHP
8.1 continues to be skipped. Sadly, this will need to be updated sporadically.
Closes GH-20512
When type == 2, the zval is not initialized, so zval_ptr_dtor() on it
will crash.
Unfortunately couldn't test with property_exists() or Reflection because
they have fast paths that go through the property info, but fortunately
there are paths that don't implement a fast path (e.g. because it
doesn't make sense at that point), like with array_column().
So we use array_column() to trigger the crash.
Closes GH-20496.
In 61884c3b52 I added these FIXME comments after I noticed that this
would cause an assertion failure. At that time I did not yet know what
to do here. I took a look at the code now and other streams return -1
and leave the file position untouched. So we do the same for phar.
This fixes the assertion failure and subsequent crashes, but also
changes one test output. However, I believe the new test output is
correct.
Closes GH-20475.
Fortunately, libxml won't allow _at this point in time_ to have more
than INT_MAX/5 attributes, so this doesn't cause issues right now.
However, if this limit is ever raised then it can cause an integer
overflow which will cause a heap overflow.
So future-proof this code by properly using safe_emalloc().
Closes GH-20472.
This aligns the behaviour with what the stubs say.
And even if one fixes the stubs the behaviour is not identical due to missing indirect handling.
This indicates that using objects is never done, so do the easy fix of changing the ZPP specifier.
Closes GH-20465
The stubs say array so in debug mode we get a ZPP violation assertion and even by fixing the stubs the behaviour is not identical due to missing indirect handling.
This indicates using objects was never done, thus use the correct ZPP specifier
We would need to escape the attributes, but there's no builtin method
that we can call in libxml2 to do so in a way consistent with the
attribute escape rules and expat.
In fact, expat just repeats the input, while we reconstruct it.
To fix the issue, and fix consistency with expat, we repeat the input as
well. This works by seeking to the start and end of the tag and passing
it to the default handler. This is fine for the parser because the
parser used in ext/xml is always in non-progressive mode, so we have
access to the entire input buffer.
Functions are case insensitive. The flush code already takes this into
account by checking for the __halt_compiler() symbol in a case
insensitive manner; however the parsing code did not do that yet.
Closes GH-20445.
In the latest version of libpcre2, the offsets appearing in some
"compilation failed" warnings have increased by one, as a result of
https://github.com/PCRE2Project/pcre2/pull/756
This is causing spurious test failures, so in this commit we replace
the hard-coded offsets by a regex that matches both values.
Gentoo-bug: https://bugs.gentoo.org/965018
Closes GH-20397
