Clear the OpenSSL error queue before performing SSL stream operations.
As we don't control all code that could possibly be using OpenSSL,
we can't rely on the error queue being empty.
Time flies, so obviously the reported uptime may differ a bit (as
already occasionally noticed on CI); we cater to that by allowing a
delay of up to one second.
The string held by the zend_type may be released if the property
type gets resolved to a CE. I initially wanted to fix this by
storing a zend_type* instead (so the property type resolution
propagates to the ReflectionType), but decided against this in
light of upcoming union types support, where we also need to
represent parts of the union, and will not have a single zend_type*
we can reference.
Use the shared empty array from ZVAL_EMPTY_ARRAY
For code that created an 10 arrays of 100000 empty arrays
(has the same result with `$assoc=true` and `{}`)
- This is the worst-case comparison, but I'd expect 0-length arrays to be fairly
common in regular data for json_decode
- The parser implementation was using function pointers so that third party
extension developers could reuse the json parser for their own
data structures, etc. (I think).
This PR is meant to let those third party extensions continue working
without changes.
Before this patch: In 0.126 seconds: added 97.99 MiB
After this patch: In 0.096 seconds: added 41.99 MiB
```php
<?php
$json = '[' . str_repeat('[],', 100000) . "null]";
$start_memory = memory_get_usage();
$start_time = microtime(true);
$result = [];
for ($i = 0; $i < 10; $i++) {
$result[] = json_decode($json);
}
$end_memory = memory_get_usage();
$end_time = microtime(true);
// Before this patch: In 0.126 seconds: added 97.99 MiB
// After this patch: In 0.096 seconds: added 41.99 MiB
printf("In %.3f seconds: added %.2f MiB\n", $end_time - $start_time, ($end_memory - $start_memory)/1000000);
// For objects
$json = '[' . str_repeat('{},', 100000) . "null]";
$start_memory = memory_get_usage();
$start_time = microtime(true);
for ($i = 0; $i < 10; $i++) {
$result[] = json_decode($json, true);
}
$end_memory = memory_get_usage();
$end_time = microtime(true);
// Before this patch: In 0.126 seconds: added 97.99 MiB
// After this patch: In 0.096 seconds: added 41.99 MiB
printf("In %.3f seconds: added %.2f MiB (objects decoded as arrays) \n", $end_time - $start_time, ($end_memory - $start_memory)/1000000);
```
Closes GH-4861.
To work around the limitation of the current rudimentary vectorcall
support in our patched libffi, we forbid yet unsupported declarations,
i.e. float/double parameters at certain positions (SIMD vector types
and HVA types are not supported anyway).
When getting the properties of a DatePeriod instance we have to retain
the proper classes, and when restoring a DatePeriod instance we have to
cater to DateTimeImmutable instances as well.
For some reason FD 120 seems to exist on macos quite often, while
FD 12 did not... Let's try an even larger number, otherwise we
should just drop this test.
Assigning to an uninitialized typed property will no longer trigger
a call to __set(). However, calls to __set() are still triggered if
the property is explicitly unset().
This gives us both the behavior people generally expect, and still
allows ORMs to do lazy initialization by unsetting properties.
For PHP 8, we should fine a way to forbid unsetting of declared
properties entirely, and provide a different way to achieve lazy
initialization.
instanceof_function() requires linked classes. I'm not reusing
unlinked_instanceof() here, because it performs class loading,
which wouldn't be right here, I think.
I'm not totally sure, but I have a strong suspicion that the fact
that this produces an error is an artifact of undefined cast behavior
(which will yield INDVAL on x86 but saturate on ARM). INF seems to
be the only value that results in an error even on x86 (variations
like -INF or NAN succeed).
It might make sense to just remove this test entirely, but for now
let's skip it on non-x86.
This stat property seems to be somewhat unreliable depending on the
filesystem. On Travis ARM64 CI a much larger payload is required
to get this value to increase.
