The fix for bug 63327[1] changed the extra size of mysqlnd allocations
from `sizeof(size_t)` to the properly aligned values; however, the
allocation in `_mysqlnd_pestrdup()` has apparently been overlooked,
which (currently) causes detectable heap corruption when running
mysqli_get_client_stats.phpt on 32bit Windows versions.
[1] <https://github.com/php/php-src/commit/338a47bb856872f9ab0db94e867333d73279ca85>
Closes GH-9724.
* PHP-8.2:
Add regression test for problem with mb_encode_mimeheader reported as GH-9683
In legacy text conversion filters, reset filter state in 'flush' function
* PHP-8.1:
Add regression test for problem with mb_encode_mimeheader reported as GH-9683
In legacy text conversion filters, reset filter state in 'flush' function
Up until now, I believed that mbstring had been designed such
that (legacy) text conversion filter objects should not be
re-used after the 'flush' function is called to complete a
text conversion operation.
However, it turns out that the implementation of
_php_mb_encoding_handler_ex DID re-use filter objects
after flush. That means that functions which were based on
_php_mb_encoding_handler_ex, including mb_parse_str and
php_mb_post_handler, would break in some cases; state left
over from converting one substring (perhaps a variable name)
would affect the results of converting another substring
(perhaps the value of the same variable), and could cause
extraneous characters to get inserted into the output.
All this code should be deleted soon, but fixing it helps me
to avoid spurious failures when fuzzing the new/old code to
look for differences in behavior.
(This bug fix commit was originally applied to PHP-8.2 when fuzzing
the new mbstring text conversion code to check for differences with
the old code. Later, Kentaro Ohkouchi kindly reported a problem with
mb_encode_mimeheader under PHP 8.1 which was caused by the same issue.
Hence, this commit was backported to PHP-8.1.)
Fixes GH-9683.
As of PHP 8.2.0, `zend_module_entry` structures are no longer copied,
so when a module is permanently loaded, and users try to dynamically
load that module again, the structure is corrupted[1], causing a
segfault on shutdown.
We catch that by checking whether any dynamically loaded module is
already loaded, and bailing out in that case without modifying the
`zend_module_entry` structure.
[1] <https://github.com/php/php-src/issues/9589#issuecomment-1263718701>
Closes GH-9689.
* Add `json_validate(string $json, int $depth = 512, int $flags = 0): bool` from https://wiki.php.net/rfc/json_validate
* In json_validate, use a different set of C no-op functions for creating/updating
arrays/objects when validating while reusing the unmodified parser/scanner code
* Forbid unsupported flags in json_validate()
* Remove test of passing NULL as parameter (normal behavior of https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg for internal functions)
Co-authored-by: jcm <juan.carlos.morales@tradebyte.com>
The issue is that PS(mod)->s_validate_sid is always defined for user modules, thus we need to check that the actual callable is set
Add another regression test to ensure current working behaviour is not broken (which was by the previous incorrect fix)
Closes GH-9638
Since mysqli can no longer be built against libmysql-client, there is
no longer the need to distinguish.
While we're at it, we also drop the superfluous is_object() checks.
Closes GH-9652.
In 0d0029d729 and 315d48b434, I changed the mappings used for Unicode
to Shift-JIS-2004, in an attempt to follow the JISC specification
more closely. However, feedback from Japanese PHP users indicates
that most users of SJIS-2004 expect 0x5C and 0x7E to be treated as
equivalent to the same ASCII bytes. This is due to a long history of
non-complying implementations which then became a de-facto standard.
Therefore, restore the earlier mappings for U+005C and U+007E.
Thanks to the GitHub user 'youkidearitai' for reporting this issue.
Fixes GH-9528.
Christoph M. Becker