The ASSERT_CALLBACK value is not validated at all -- it's possible
to set it to an arbitrary value. As such, the function can also
return any value or type (even without outright abuse, the opcache
func info was wrong in that the return can be rcn, and the array
can be array_of_ref).
The deprecation of passing null is thrown otherwise.
If the timeout is calculated conditionally before calling stream_select(), passing to avoid the deprecation seems unreasonable, example:
7d4bbc6e0b/lib/Loop/NativeDriver.php (L286)
Also enforce that if $seconds is null, then $microseconds should be null as well. However 0 is still accepted (with deprecation) for backwards compatibility.
fsync is a straightforward wrapper around the same C function
(implemented on Windows API as _commit() with identical signature).
From the man pages:
fsync() transfers ("flushes") all modified in-core data of (i.e.,
modified buffer cache pages for) the file referred to by the file
descriptor fd to the disk device (or other permanent storage
device) so that all changed information can be retrieved even if
the system crashes or is rebooted. This includes writing through
or flushing a disk cache if present. The call blocks until the
device reports that the transfer has completed.
RFC: https://wiki.php.net/rfc/fsync_function
Closes GH-6650.
The actual name of this function is dir(), but ever since it was
introduced in PHP 3, its internal name was "getdir", leading to it
being mistaken for an alias. This went unnoticed until the switch
to stubs for generating arginfo, at which point getdir() became a
real but undocumented function.
Fixes bug #80914.
Closes GH-6855.
This changes ini_set() to accept all scalar types
(string|int|float|bool|null) for the new value. The idea here is
that while the INI system ultimately works with strings, its value
interpretation is designed to be consistent with PHP's casting rules,
e.g. "1" and "" are interpreted as boolean true and false respectively.
I personally believe that writing ini_set('precision', 10) makes more
sense than ini_set('precision', '10'), and find strict_types to be
unnecessarily pedantic here.
Closes GH-6680.
The get_info() handler should never fail, but even if it does,
we should still return a proper info array -- it doesn't make
sense that a completely incorrect hash returns an info array,
but a hash that is recognized but for which the options can't
be extracted would return null.
This function tests if an array contains only sequential integer keys. While
list isn't an official type, this usage is consistent with the community usage
of "list" as an annotation type, cf.
https://psalm.dev/docs/annotating_code/type_syntax/array_types/#lists
Rebased and modified version of #4886
- Use .stub.php files
- Add opcache constant evaluation when argument is a constant
- Change from is_list(mixed $value) to array_is_list(array $array)
RFC: https://wiki.php.net/rfc/is_list
Co-Authored-By: Tyson Andre <tysonandre775@hotmail.com>
Co-Authored-By: Dusk <dusk@woofle.net>
Closes GH-6070
To make things a bit less weird, split off the function name into
a zval stored separately from the arguments. This allows us to
use normal zpp and get standard behavior.
Make the behavior of substr(), mb_substr(), iconv_substr() and
grapheme_substr() consistent when it comes to the handling of
out of bounds offsets. substr() will now always clamp out of
bounds offsets to the string boundary. Cases that previously
returned false will now return an empty string. This means that
substr() itself *always* returns a string now (like mb_substr()
already did before.)
Closes GH-6182.
Cross checking implementations from other languages, empty strings
are always allowed. PHP's output is peculiar due to it's insistence
to encode a trailing \0, but otherwise sensible and does round-trip
as expected.
Return "0000" instead of false to have a consistent return type.
"0000" is already a possible return value if the string doesn't
contain any letters, such as with soundex(" "). We can treat the
case of soundex("") exactly the same.
php_unescape_html_entities() never returns null, so this function
can never return false.
php_unescape_html_entities() probably should be failing with OOM
for the "overflow" case, but even if it did, it would not be
signalled through a false return value.
In preparation for generating method signatures for the manual.
This change gets rid of bogus false|null return types, a few unnecessary trailing backslashes, and settles on using ? when possible for nullable types.
* The array "subject" of a function gets called $array.
* Further parameters should be self-descriptive if used
as a named parameter, and a full word, not an abbreviation.
* If there is a "bunch more arrays" variadic, it gets
called $arrays (because that's what was already there).
* A few functions have a variadic "a bunch more arrays,
and then a callable", and were already called $rest.
I left those as is and died a little inside.
* Any callable provided to an array function that acts
on the array is called $callback. (Nearly all were already,
I just fixed the one or two outliers.)
* array_multisort() is beyond help so I ran screaming.
The second and third arguments are not always the sort_order and
sort_flags -- they can also be in reverse order, or be arrays
altogether. Move them into the variadic parameter to avoid awkward
error messages.
Both of these functions are well-defined when used with a single
array argument -- rejecting this case was an artificial limitation.
This is not useful when called with explicit arguments, but removes
edge-cases when used with argument unpacking:
// OK even if $excludes is empty.
array_diff($array, ...$excludes);
// OK even if $arrays contains a single array only.
array_intersect(...$arrays);
This matches the behavior of functions like array_merge() and
array_push(), which also allow calls with no array or a single
array respectively.
Closes GH-6097.
crypt() without salt generates a weak $1$ MD5 hash. It has been
throwing a notice since 2013 and we provide a much better alternative
in password_hash() (which can auto-generate salts for strong
password hashes), so keeping this is just a liability.
