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.
Normally incrementing the refcount on just function_name is
sufficient. However, if the callable is of the form 'X::y' inside
an instance method, this will capture $this in fcc.object, which
also needs to be retained.
The fci_addref/fci_release helpers should likely be exported as
a general API, as we may have this problem in other places as
well.
Fixes oss-fuzz #39778.
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
Otherwise we're sending the signal to the shell, not the sleep
process, and it will continue sleeping.
This also illustrates a minor issue without our array proc_open()
support: We don't preserve the passed arguments in the
proc_get_status() output.
Use ASCII case conversion instead of locale-dependent case conversion in
the following places:
* grapheme_stripos() and grapheme_strripos() in the "fast" path
* ldap_get_entries()
* oci_pconnect() for case folding of parameters when constructing a key
into the connection or session pool
* SoapClient: case folding of function names
* get_meta_tags(): case conversion of property names
* http stream wrapper: header names
* phpinfo(): anchor names
* php_verror(): docref URLs
* rfc1867.c: Content-Type boundary parameter name
* streams.c: stream protocol names
Using locale-dependent case folding for these cases is either
unnecessary or actively incorrect. These functions could have
misbehaved when used with certain locales (e.g. Turkish).
Closes GH-7511.
Currently, resource IDs are limited to 32-bits. As resource IDs
are not reused, this means that resource ID overflow for
long-running processes is very possible.
This patch switches resource IDs to use zend_long instead, which
means that on 64-bit systems, 64-bit resource IDs will be used.
This makes resource ID overflow practically impossible.
The tradeoff is an 8 byte increase in zend_resource size.
Closes GH-7436.
If we assemble a zend_string manually, we need to end it with a NUL
byte ourselves.
We also fix the size calculation for that zend_string; there is no need
for the extra byte for each part, and we don't have to multiply by two,
since we're using DnsQuery_A(), not DnsQuery_W () (in which case we
would have to do the character set conversion, anyway). This avoids
over-allocation, and the need to explicitly set the string length.
Finally, we use the proper access macro for zend_strings.
Closes GH-7427.
Quoting from UPGRADING:
- A leading dollar in a quoted string can now be escaped: "\${" will now be
interpreted as a string with contents `${`.
- Backslashes in double quoted strings are now more consistently treated as
escape characters. Previously, "foo\\" followed by something other than a
newline was not considered as a teminated string. It is now interpreted as a
string with contents `foo\`. However, as an exception, the string "foo\"
followed by a newline will continue to be treated as a valid string with
contents `foo\` rather than an unterminated string. This exception exists to
support naive uses of Windows file pahts as "C:\foo\".
Closes GH-7420.
basic_functions.c already has a macro for returning an ini
value to userland, so make use of it for get_cfg_var() as well,
after generalizing it to not write to return_value in particular.
This property was formerly used to hold the php_stream_filter
pointer for destruction purposes. However, this is no longer used,
and we don't need to create this resource at all.
The putenv value is stored in environ. If for some reason we
fail to restore it on shutdown, make sure that we fail gracefully
by using a system allocated value, rather than a ZMM allocated one.
This is an additional mitigation for bug #81316 style issues if
all else fails.
Christoph M. Becker