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.
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.
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
Strings loaded from the file cache can not have a CE cache, because their cache
slot is invalid. Remove the IS_STR_CLASS_NAME_MAP_PTR flag from these strings.
We can also avoid updating the str flags in SERIALIZE_STR(), since the same
updates must also be done in UNSERIALIZE_STR().
This was already done for interned strings, but not for non-interned ones.
Fixes GH-20329
Closes GH-20337
Either the buffer size or the return value needs to be checked.
From a quick look into the tidy source code, this can't fail right now
for our use case in practice, but it might in the future.
Closes GH-20389.
These tests:
- ext/standard/tests/network/udp4loop.phpt
- ext/sockets/tests/socket_create_listen.phpt
- ext/sockets/tests/socket_create_listen-win32.phpt
all use port 31338. socket_create_listen.phpt and its win32 variant are mutually
exclusive, so they can't conflict. While udp4loop.phpt tries multiple ports, the
other tests do not. If udp4loop.phpt runs first and socket_create_listen.phpt
starts before it ends, the port is still blocked. Bump the start port for
udp4loop.phpt to avoid conflicts.
Both enums and integers map to TidyInteger, however, in the TidyInteger
case we always used zval_get_long(). So for a non-numeric string, this
would get turned into 0. 0 is the first enum value in that case, so the
wrong enum value could be selected.
To solve this, add special handling for strings and (stringable) objects
such that we can explicitly check for numeric strings, and if they're
not, handle them as normal strings instead of as 0.
Closes GH-20387.
