The 'flags' field in spl_dllist_it was formerly unused. This means that if one started to
iterate over an SplDoublyLinkedList using 'foreach', and then *changed* the iteration mode
halfway, the 'foreach' loop would start iterating in the opposite direction. Probably this
was not what was intended.
Therefore, use the 'flags' field in spl_dllist_it for iteration via 'foreach'. For explicit
iteration using methods like '::next()' and '::current()', continue to use the flags in
the SplDoublyLinkedList object itself.
The 'int dummy' parameter to this function makes it appear that it was intended as a
signal handler, but it is not being used as such. So remove the redundant parameter.
The FILE_BINARY (and FILE_TEXT) constants are not really valid or useful
constants. It looks like they were added in 5.2.7 and have "no effect,
and are only available for forward compatibility."
See: https://www.php.net/manual/en/filesystem.constants.php
The default value of the file_put_contents() flags parameter is 0 and
FILE_BINARY is set to 0, so removing it doesn't change functionality.
P.S. Maybe those constants should be deprecated or removed in 8.0.
Closes GH-5556.
* PHP-7.4:
Fix#78876: Long variables cause OOM and temp files are not cleaned
Fix#78875: Long filenames cause OOM and temp files are not cleaned
Update NEWS for 7.2.31
Update CREDITS for PHP 7.2.30
Update NEWS for PHP 7.2.30
* PHP-7.3:
Fix#78876: Long variables cause OOM and temp files are not cleaned
Fix#78875: Long filenames cause OOM and temp files are not cleaned
Update NEWS for 7.2.31
Update CREDITS for PHP 7.2.30
Update NEWS for PHP 7.2.30
* PHP-7.2:
Fix#78876: Long variables cause OOM and temp files are not cleaned
Fix#78875: Long filenames cause OOM and temp files are not cleaned
Update NEWS for 7.2.31
Update CREDITS for PHP 7.2.30
Update NEWS for PHP 7.2.30
We must not cast `size_t` to `int` (unless the `size_t` value is
guaranteed to be less than or equal to `INT_MAX`). In this case we can
declare `array_len` as `size_t` in the first place.
This deprecates:
ReflectionParameter::isArray()
ReflectionParameter::isCallable()
ReflectionParameter::getClass()
These APIs have been superseded by ReflectionParameter::getType()
since PHP 7.0. Types introduced since that time are not available
through the old APIs, and their behavior is getting increasingly
confusing. This is how they interact with PHP 8 union types:
* isArray() will return true if the type is array or ?array,
but not any other union type
* Same for isCallable().
* getClass() will return a class for T|int etc, as long as the
union only contains a single type. T1|T2 will return null.
This behavior is not particularly reasonable or useful, and will
get more confusing as new type system extensions are added.
Closes GH-5209.
We must not attempt to access arbitrary union members when retrieving
debug info, because that may not be valid. Therefore we do no longer
dereference pointer types inside of unions, but report their address as
string in `%p` format instead.
array_column() reimplements array key handling in a way that does
not match standard array key behavior in PHP. Avoid this by making
use of the standard API.
Of course, there is a minor backwards compatibilty break here,
e.g. people could be relying on objects getting cast to string
instead of throwing.
Closes GH-5487.
I reverted this previously for 7.4 because of bug #78769. Relanding
it now for master, because I still believe that this change is
right, and if it causes complications, those indicate a bug elsewhere.
---
These were checking whether the instruction set is supported by
the host CPU, however they were only used to condition on whether
this instruction set is targeted at all. It would still use dynamic
dispatch (e.g. based on ifunc resolvers) to select the actual
implementation. Whether the target is guaranteed to support the
instruction set without dispatch is determined based on pre-defined
macros like __SSE2__.
This removes the configure-time builtin cpu checks to remove
confusion. Additionally this allows targeting an architecture that
is newer than the host architecture.
Behavior is same as for (int) $resource, just under a clearer
name. Also type-safe, in that the parameter actually needs to
be a resource.
Closes GH-5427.
This is a funny one. I discovered that lstat_stat_variation10.phpt was failing every
now and again when the PHP test suite was run on my dev PC. The output from the failing
test showed that the atime (access time) of the directory created in the test was changing
between these lines:
$old_stat = stat($dirname);
clearstatcache();
sleep(1);
var_dump( is_dir($dirname) );
$new_stat = stat($dirname);
Could is_dir() be accessing the directory and changing the atime? strace showed that is_dir
was only issuing a single stat() syscall. Could stat() change the atime? No, no, that would
just be perverse. Nobody would be stupid enough to implement the kernel in that way.
Checked the kernel source, found that the function called when atime needs to be updated
appears to be touch_atime(). Broke out the BCC kernel tracing tools and ran this one
while running the flaky test case in a loop:
sudo trace -I<kernel src dir>/include/linux/path.h -I<same>/include/linux/dcache.h 'touch_atime(struct path *path) "%s", path->dentry->d_name.name'
Inspecting the results showed that something called "git_thread" was occcasionally updating
the atime on the directory in question!! What on earth...???
The PID shown by trace revealed that this was a background thread for Sublime Text 3.
Sublime now has git integration and shows when there are untracked or modified files. It
seems that it uses a background thread to regularly scan the project directory and look
for new and modified files. This was causing the atime to change.
Even though other developers may not be running ST3, there are any number of reasons why
a background process might recurse through various directories and could cause the atime
to change unexpectedly. Therefore, update the test case so it doesn't fail in such cases.
Closes GH-5553.
The function name gets printed here now, with illegal chars
substituted in the arg. This slipped through previously, because
the test only runs under USE_ZEND_ALLOC=0. We remove that check
as well, because the test behaves the same regardless of which
allocator is used, even if the original bug only reproduces under
USE_ZEND_ALLOC=0.
Alex Dowad