It can return false if the resource type is wrong.
```
php > var_export(hash_update_stream(hash_init('md5'),
imagecreate(1,1)));
Warning: hash_update_stream(): supplied resource is not a valid stream
resource in php shell code on line 1
false
```
The return types were initially added in
c88ffa9a56
This can also return an array. See
https://www.php.net/manual/en/function.time-nanosleep.php#refsect1-function.time-nanosleep-returnvalues
> If the delay was interrupted by a signal, an associative array will be
returned with the components:
>
> - seconds - number of seconds remaining in the delay
> - nanoseconds - number of nanoseconds remaining in the delay
Sending a SIGUSR1 to the below program would trigger this behavior.
```
pcntl_signal(\SIGUSR1, function ($signo, $signinfo) {
echo "Handling a signal $signo\n";
});
echo "Sleeping for 100 seconds\n";
var_export(time_nanosleep(100, 0));
```
The incomplete signature existed since c88ffa9a5.
No phpt tests existed for time_nanosleep returning an array
The smart branch logic assumed b->start refers to the old offsets,
while b->start was already adjusted to the new offsets at this
point. Delay the change until later.
When cleaning nops in the dfa pass, we were always keeping the
smart branch inhibiting nop that occurs directly before the jump
instruction. However, as we skip unreachable blocks entirely, it
may happen that we need to keep a nop that occurs further back,
prior to the unreachable blocks. Account for that case now.
We should really do something about the smart branch situation,
this is very fragile...
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.
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.
We cannot replace an op1_def opcode with an ASSIGN, if it also has
a used res_def. Usually this doesn't happen because the res_def use
can be eliminated first. The example is a case where operand replacement
on the res_def use fails.
Nikita Popov