Previously, if an object had RC1 it would never be recorded in
php_serialize_data.ht because it was assumed that it could not be encountered
again. This assumption is incorrect though as the object itself may be saved
inside an array with RCn. This results in a new instance of the object, instead
of a second reference to the same object.
This is solved by tracking these objects in php_serialize_data.ht. To retain
performance, track if the current object resides in a potentially nested RCn
array. If not, and if the object is RC1 itself it may be omitted from
php_serialize_data.ht.
Additionally, we may treat the array root itself as RC1 because it may not
appear in the object graph again without recursion. Recursive arrays are still
somewhat broken even with this change, as the tracking of the array only happens
when the reference is encountered, thus resulting in a -> a' -> a' for a self
recursive array a -> a. Recursive arrays have limited support in serialize
anyway, so we ignore this case for now.
Co-authored-by: Dmitry Stogov <dmitry@zend.com>
Co-authored-by: Martin Hoch <martin@littlerobot.de>
Closes GH-11349
Closes GH-11305
the old flag check was flawed and would miss some flags, for example:
file(__FILE__, FILE_APPEND);
is invalid, but the old flags error check would miss it: https://3v4l.org/b2W9u
Closes GH-11483
* support running testsuite with negative niceness
a bug in the regex would break getNice() if the current niceness was negative, which would make the whole test fail.
Previously:
this would fail:
time sudo nice --adjustment=-19 ./php run-tests.php -j$(nproc) -x --offline ext/standard/tests/general_functions/proc_nice_basic.phpt --color --show-all
and this would work:
time sudo ./php run-tests.php -j$(nproc) -x --offline ext/standard/tests/general_functions/proc_nice_basic.phpt --color --show-all
* Update ext/standard/tests/general_functions/proc_nice_basic.phpt
Co-authored-by: Michael Voříšek <mvorisek@mvorisek.cz>
---------
Co-authored-by: Michael Voříšek <mvorisek@mvorisek.cz>
This is an alternative implementation for GH-10406 that resets the
has_buffered_data flag after finishing stream read so it does not impact
other ops->read use like for example php_stream_get_line.
Closes GH-11421
This adds support for the completed event. Since the read handler could
be entered twice towards the end of the stream we remember what the eof
flag was before reading so we can emit the completed event when the flag
changes to true.
Closes GH-10505.
This merges all usages of emitting an offset TypeError into a new ZEND_API function
zend_illegal_container_offset(const zend_string* container, const zval *offset, int type);
Where the container should represent the type on which the access is attempted (e.g. string, array)
The offset zval that is used, where the error message will display its type
The type of access, which should be a BP_VAR_* constant, to get special message for isset/empty/unset
warning: check of ‘*resource.scheme’ for NULL after already dereferencing it [-Wanalyzer-deref-before-check]
186 | use_ssl = resource->scheme && (ZSTR_LEN(resource->scheme) > 4) && ZSTR_VAL(resource->scheme)[4] == 's';
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Although resource->scheme is already dereferenced on line 163 in the IF condition
RFC 7231 states that status code 307 should keep the POST method upon
redirect. RFC 7538 does the same for code 308. Although it's not
mandated by the RFCs that PATCH is also kept (we can choose), it seems
like keeping PATCH will be the most consistent and understandable behaviour.
This patch also changes an existing test because it was testing for the
wrong behaviour.
Closes GH-11275.
It's possible that the server already sent in more data than just the headers.
Since the stream only accepts progress increments after the headers are
processed, the already read data is never added to the process.
We account for this by adjusting the progress counter by the difference of
already read header data and the body.
For the test:
Co-authored-by: aetonsi <18366087+aetonsi@users.noreply.github.com>
Closes GH-10492.
A negative value like -1 may overflow and cause incorrect results in the
timeout variable, which causes an immediate timeout. As this is caused
by undefined behaviour the exact behaviour depends on the compiler, its
version, and the platform.
A large overflow is also possible, if an extremely large timeout value
is passed we also set an indefinite timeout. This is because the timeout
value is at least a 64-bit number and waiting for UINT64_MAX/1000000
seconds is waiting about 584K years.
Closes GH-11183.
