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
Remi Collet