While it may not be desired, `DateInterval::$f` supports negative
values, at least with regard to calculations. We still need to guard
from assigning double values which are out of range for signed 64bit
integers (which would be undefined behavior). zend_dval_to_lval() does
this by returning `0` instead of triggering UB. This way we can avoid
setting the invalid marker, which doesn't work as expected anyway.
We must not do that only for unserialization, but also when the property
is set in the first place.
We need to adapt some of the existing tests wrt. this behavior. In
particular, we check for an arbitrary value in bug79015.phpt, to cater
to differences between 32bit and 64bit architectures.
Closes GH-7575.
The current error message is incorrect -- the problem here is not
that the property is invalid, but that these methods are unusable
prior to loading data, same as read().
We backport the respective upstream fix[1] to our bundled pcre2lib plus
the follow-up fix[2] for a functional regression.
[1] <dc5f966635>
[2] <e7af7efaa1>
Closes GH-7573.
Use the proper error reporting mechanism rather than throwing a
warning. This requires something of a hack because we don't have
direct access to the connection object at this point.
This now prints an additional
> CONTEXT: unnamed portal parameter $1 = ''
on azure, presumably as a result of a version update or configuration
change. Strip this additional line from the error info, the same as
already done in one other place in the test.
Don't allow calling fclose() on the stream while in the user
filter callback. This is basically the same protection as xp_ssl
streams use during callback invocations.
There are more issues in this general area (e.g. stack overflow
on stream_filter_remove), but this addresses freeing the stream
during the filter callback invocation at least.
This was loading EG(uninitialized_value) into r0 rather than
FCARG1a.
However, if we fix this issue an existing test fails because
the undef var warning promoted to exception is not caught early
enough, so we need to explicitly check for the exception before
performing the type check.
