On IBM i, getifaddrs is available renamed as Qp2getifaddrs; freeifaddrs
and struct ifaddr follow a similar fate. I assume this is in case AIX
decides to add it (as if). As such, just use the same implementation,
but rename the standard ones to the IBM i definitions and include its
header.
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 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.
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.
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.
User-defined functions can't have multiple parameters with the same name.
Don't do that for var_dump/debug_zval_dump.
Consistently use array $array to match docs
Fix typo in UPGRADING
Fixes GH-6015
