While the reason-phrase in a HTTP response status line is usually
short, there is no actual limit specified by the RFCs. As such, we
must not assume that the line fits into the buffer (which is currently
128 bytes large).
Since there is no real need to present the complete status line, we
simply read and discard the rest of a long line.
Co-authored-by: Tim Düsterhus <timwolla@googlemail.com>
Closes GH-9319.
This fix is another solution to replace d0527427be, use zend_try and zend_catch to make sure persistent stream will be released when error occurred.
Closes GH-9332.
This reverts commit d0527427be.
This patch makes Swoole/Swow can not work anymore, because Coroutine will yield to another one during socket operation, EG(record_errors) assertion will always fail, and zend_begin_record_errors() was only used during compile time before.
Note: zend_emit_recorded_errors() and the typo fix are reserved.
This is not actually related to SSL handshake but stream socket creation
which does not clean errors if the error handler is set. This fix
prevents emitting errors until the stream is freed.
The comparator function used at ksort in SORT_REGULAR mode
need to be consistent with basic comparison rules. These rules
were changed in PHP-8.0 for numeric strings, but comparator
used at ksort kept the old behaviour. It leads to inconsistent
situations, when after ksort the first key is GREATER than some
of the next ones by according to the basic comparison operators.
Closes GH-9293.
Apparently, on Cirrus CI FreeBSD chmodding a file to 0444 doesn't make
it readonly. So in this case, we skip the test.
[1] <https://github.com/php/php-src/pull/7975>
We explicitly check for an exception after the logging attempt, and
bail out in that case.
Co-authored-by: Tim Düsterhus <timwolla@googlemail.com>
Closes GH-7878.
Since we're going to read from the current stream position anyway, the
`max_len` should be the size of the file minus the current position
(still catering to potentially filtered streams). We must, however,
make sure to cater to the file position being beyond the actual file
size.
While we're at, we also fix the step size in the comment, which is 8K.
A further optimization could be done for unfiltered streams, thus
saving that step size, but 8K might not be worth it.
Closes GH-7693.
Modify dns_get_record to test for records result based on dns_errno to
accommodate modern FreeBSD, for which res_nsearch() does not update
h_errno directly. Add new php_dns_errno macro, and have it consult
statp->res_h_errno when OS has res_nsearch().
Closes GH-7655.
PHP 8.0 did not accept null for the usec argument, PHP 8.1 only
accepts null. This means you can't easily write code compatible
with both without triggering at least a deprecation warning.
Drop the deprecation warning for now.
Closes GH-7617.
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.
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.
Change error message of sprintf/printf for missing/invalid position
specifier to make it clear that this is talking about the specifier,
not the number of arguments passed to the function. Also mention
the upper limit of INT_MAX.
Closes GH-7515.
Test case "ext/standard/tests/array/range.phpt" failed on ARM64 machine
only under RELEASE mode.
How to reproduce it:
```
./buildconf -f; ./configure; make -j 128
make test TESTS="-d opcache.enable=1 -d opcache.enable_cli=1 ext/standard/tests/array/range.phpt"
```
Root cause:
I suspect the root cause is that on ARM64 machine, PHP RELEASE mode
produces different values for internal function range() compared to
DEBUG mode.
Take the downsized test case downsize-range.php [1] as an example. We
applied the check-element.diff patch to check the original values. Note
that we print out the floating point numbers with precision 16.
From the outputs in file output.md, we can see the 7-th and 9-th
elements are different between RELEASE and DEBUG.
To be honest, I didn't get where such difference comes from and probably
this is due to different compilation options used by RELEASED and DEBUG.
Fix:
After commit [2], serialize_precision is used for var_dump(). As a
result, the pre-set "precision=14" didn't work actually.
In this patch, we turn to set serialize_precision as 14 and therefore
the difference between RELEASE and DEBUG can be eliminated.
Note-1: this failue didn't occur on x86 machine.
Note-2: in my local test, this is the only test case which behaves
differently on ARM64 machine under RELEASE and DEBUG mode.
[1] https://gist.github.com/shqking/0d55abf8dbaafde4a00ea9304e71f06b
[2] https://github.com/php/php-src/commit/a939805
Change-Id: I9293e990925590f8d7cfb2462d8d760abf76069f
