mbstring has a great deal of dead code. Some common types are:
- Default switch clauses which will never be taken
- If clauses intended to convert codepoints which were not present in
a conversion table... but the codepoint in question *is* in the table,
so the if clause is not needed.
- Bounds checks in places where it is not possible for a value to ever
be out of bounds.
- Checks to see if an unmatched Unicode codepoint is in CP932 extension
range 3... but every codepoint in range 3 is also in range 2, so no
codepoint will ever be matched and converted by that code.
If certfile/private_key points to a file that doesn't exist, it throw a warning and return failure now.
Also fixed sni_server tests.
Co-authored-by: Nikita Popov <nikita.ppv@googlemail.com>
We need to allocate buffers for the file mapping names which are large
enough for all potential keys (`key_t` is defined as `int` on Windows).
Regarding the test: it's probably never a good idea to use hard-coded
keys (should always use `ftok()` instead), but to reliably reproduce
this Windows specific issue we need to, and it shouldn't be an issue on
that OS.
Closes GH-7448.
This API had rather peculiar behavior in case the provided function
is not callable. For some types of failures, it would silently
return FAILURE (e.g. a function does not exist), while for others
(e.g. a class does not exist) it would generate a warning. Depending
on what the calling code does, this can either result in silent
failure or duplicate errors.
This commit switches the contract such that zend_call_function()
always (*) succeeds, though that success might be in the form of
throwing an exception. Calling a non-callable will now consistently
throw an exception.
There are some rare callers that do want to ignore missing methods,
for legacy APIs that are specific with optional methods. For these
use cases a new zend_call_method_if_exists() API is provided.
Calling code generally does not need to explicitly check for and
report zend_call_function() failures -- it can rely on
zend_call_function() having already done so. However, existing
code that does check for failure should continue to work fine.
(*) The only exception to this is if EG(active) being false during
late engine shutdown. This is not relevant to most code, but code
running in destructors and similar may need to be aware of the
possibility.
If buf_len is zero, this would leave behind a dangling pointer
to an already released header.str. Make sure this can't happen
by always overwriting the pointer.
Closes GH-7376.
Alex Dowad