This header declaration is never supposed to be interpreted as
definition; otherwise, the handlers are not properly initialized, what
happens, for instance, with ASan instrumented MSVC builds.
Closes GH-7827.
Like `hash_file()`, `hash_hmac_file()` expects a filename, and not some
string data. Fixing this now, constitutes a (hopefully small) BC break
though.
Closes GH-7828.
These can be handled by the generic code. Worth noting that count
will usually go through ZEND_COUNT, and chr on constants is
evaluated in the compiler, so these are not particularly compile-time
sensitive either.
While the `path` is not supposed to be `NULL` for normal operation, it
is possible to create `SplFileInfo` objects where that is the case, and
we must not follow the null pointer.
Closes GH-7814.
On NetBSD, ifconf.ifc_buf member, unlike most of platforms, is a void
pointer.
We also fix the cpuinfo declarations with empty parameter lists.
Closes GH-7819.
When converting text to/from wchars, mbstring makes one function call
for each and every byte or wchar to be converted. Typically, each of
these conversion functions contains a state machine, and its state has
to be restored and then saved for every single one of these calls.
It doesn't take much to see that this is grossly inefficient.
Instead of converting one byte or wchar on each call, the new
conversion functions will either fill up or drain a whole buffer of
wchars on each call. In benchmarks, this is about 3-10× faster.
Adding the new, faster conversion functions for all supported legacy
text encodings still needs some work. Also, all the code which uses
the old-style conversion functions needs to be converted to use the
new ones. After that, the old code can be dropped. (The mailparse
extension will also have to be fixed up so it will still compile.)
In a2bc57e0e5, mb_detect_encoding was modified to ensure it would never
return 'UUENCODE', 'QPrint', or other non-encodings as the "detected
text encoding". Before mb_detect_encoding was enhanced so that it could
detect any supported text encoding, those were never returned, and they
are not desired. Actually, we want to eventually remove them completely
from mbstring, since PHP already contains other implementations of
UUEncode, QPrint, Base64, and HTML entities.
For more clarity on why we need to suppress UUEncode, etc. from being
detected by mb_detect_encoding, the existing UUEncode implementation
in mbstring *never* treats any input as erroneous. It just accepts
everything. This means that it would *always* be treated as a valid
choice by mb_detect_encoding, and would be returned in many, many cases
where the input is obviously not UUEncoded.
It turns out that the form of mb_convert_encoding where the user passes
multiple candidate encodings (and mbstring auto-detects which one to
use) was also affected by the same issue. Apply the same fix.
Alex Dowad