This finally solves issues with DBSC console codepages, and in
general improves the console codepage switching. When
module_initialized, all the possible encoding INI settings with
regard to possible modifications are set, and that's the
right moment to switch the console codepage in regard to I/O.
CJK glyphs might take more than 1 cell, so then visual issues
can occur, when switching console codepage back and forth. Users
are free to use ini_set(), but any visual issues are then up to
the user responsibility.
Particularly on slower VMs, the sporadic fails can still happen.
The timing is kept in an uncritical range, but allows the tests
pass there. Mayby, it'd make sense to introduce a new group for
this kind of tests, so tests requiring exact time measurement
can be avoided on unsuitable environments.
If PHP CLI is used with programs with no Unicode support, the default
PHP console codepage might cause backward incompatible behaviors. This
is solved with this patch by separating the handling of I/O codepage.
As per https://wiki.php.net/rfc/default_encoding input_encodnig and
output_encoding are centralized INI settings, so they're used for the
purpose of adjusting the codepage. This gives user the ability to use
UTF-8 internally, while letting the system API to convert the output
to a compatible codepage. This also might solve the font issues on
systems without good true type support.
Note, that there no change to the default behavior - if input and
output encoding are not set, which is the default case, the default
charset applies to both console input and output. The patch is just
a compilment to the backward compatibility, not more and not less.
Insert a lot more DEREFs. Some may not be necessary, but better
safe than sorry. I'm thinking the soap_hash_str_find_deref function
should become part of the zend_hash API -- we need this in many
places.
The problem was manifestated only with BIT columns and only when more than
one row was fetched. The problem was coming from the fact that in pre-7.0
times mysqlnd was using a no-copy optimization. This optimization kept the
strings (and also the BIT mask equivalents as strings) in the packet and the
zval referred to them. 7.0+ zvals cannot use no-copy and always copy. Because
of this the allocated memory for the packet was reduced by 1 by the person who
ported the driver, but the starting address of the bit area wasn't reduced.
Because of this the bit_area started at wrong address and the length decoded
wrong.
T_NUM_STRING follows the rules of symtable numeric string
conversion. If the offset isn't an integer under those rules, it
is treated as a string. This should apply to negated T_NUM_STRINGs
as well.
