As noted on https://bugs.php.net/bug.php?id=80073, I don't think
having this limitation makes sense. The similar_text() function
has much worse asymptotic complexity than levenshtein() and does
not enforce such a limitation. levenshtein() does have fairly high
memory requirements, but they are a fixed factor of the string
length (and subject to memory limit).
This is an artifact of the shared implementation with readdir() etc.
The method versions should not accept an explicit dir handle, as
they work on the dir handle from the object.
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.
The 32-bit tests work on both 32-bit and 64-bit. I dropped the
64-bit variants as they only test one additional case that I don't
think adds particular value.
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.
We have to log errors in `stream_opener` callbacks to the wrapper's
error log, because otherwise we may pick up an unrelated `errno` or a
most generic message.
Closes GH-6187.
Normalize the behavior between the file functions and those on
SplFileObject.
Be consistent about throwing regardless of whether the delimiter etc
is empty or has too many characters. I don't think it's worthwhile
to distinguish these cases.
Back when we looked into this originally, there was some hope that
we might want to add support for multiple-character delimiter etc,
but after a cursory look, I really don't think this is going to
happen (for fputcsv maybe, but for fgetcsv this just makes an already
broken function much more complicated.)
Closes GH-6188.
If restoring of any not registered built-in wrapper is requested, the
function is supposed to fail with a warning, so we have to check this
condition first.
Furthermore, to be able to detect whether a built-in wrapper has been
changed, it is not sufficient to check whether *any* userland wrapper
has been registered, but rather whether the specific wrapper has been
modified.
Closes GH-6183.
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.
The implementation here was pretty confused. In reality the only
error condition it has right now is that for a string input,
from & length cannot be arrays.
The fact that the array lengths are the same was probably supposed
to be checked for the case of array input, as it wouldn't matter
otherwise.
