The arena allocator has no problem with zero-size allocations (and
will just return the same pointer for each in this case), so just
do that to avoid null pointers.
mysqli has an uncommon approach to 64-bit compatibility:
it will convert numbers that can't be represented on 32-bit
platforms to a string.
This is documented at
https://www.php.net/manual/en/mysqli-stmt.affected-rows.php#refsect1-mysqli-stmt.affected-rows-returnvalues
So if there's a query to a remote mysqli server that affects
more than 2.2 billion rows, then the opcache inference might be
incorrect.
(It's possible to add a MAY_BE_STRING_ON_32_BIT_PLATFORM bitflag macro to
account for this, but I don't think there's a need or want to?)
Patches 3162285b86
This is based on the list of php 7.4 functions using
MYSQLI_RETURN_LONG_INT in mysqli_api.c
https://www.php.net/manual/en/mysqli.get-charset.php
tests/mysqli_field_seek.phpt has a test of this returning an object.
Looking at the source in ext/mysqli/mysqli_nonapi.c,
this should be object|null, not array|null
This might actually cause bugs in opcache's inferences,
(no proof of this)
so it might make sense to pull this patch into an earlier minor version.
ext/gd/gd.c seems to return null for wrong parameter count, false for
error, and long otherwise. See https://php.net/imagecolorallocate
In php 8.0, the MAY_BE_NULL can probably be removed.
This should only have one r.
http://php.net/get_parent_class mentions that it returns string|false
Also, I'm not 100% sure if this is right - should this include
MAY_BE_NULL to handle the case of too many parameters?
(then again, get_called_class() also returns null in the global scope)
```
php > var_export(get_parent_class(2,3));
Warning: get_parent_class() expects at most 1 parameter, 2 given in php
shell code on line 1
NULL
```
Even though we don't need it at runtime, add the BIND_IMPLICIT
flag to BIND_STATIC as well, so we can distinguish this case in
type inference.
This fixes a JIT miscompile in arrow_functions/002.phpt.
The num_args does not include variadics, so a "zero-arg" function
may accept additional arguments through that. No functions seem
to be affected right now, but they will be after #4175.
The num_args does not include variadics, so a "zero-arg" function
may accept additional arguments through that. No functions seem
to be affected right now, but they will be after #4175.
We need to check result_use rather than result_def for a null zval.
Previously we were later assuming that the null zval is really a
partial array, which does not go well.
