This is just a hotfix as there are still drivers with no full
ODBC 3.x support. This patch origins from bug #68350 which was
solved by the proper 3.0 migration, another driver (Sage)
turned out to have the real issue.
Temporary variable indicating column field type ID should be
reset to default for loop iteration (i.e. every column in the
record set. The old buggy code made it persist across all columns
leading to invalid reads from the buffer, if for example a DATE
column was preceded by a VARCHAR column.
* master: (46 commits)
PHP_INT_MIN and _MAX tests
NEWS and UPGRADING
Added PHP_INT_MIN
Fix wrong lenght size
Bug #51096 - Remove unnecessary ? for first/last day of
Moved streams related functions to xp_ssl.c
Remove duplicate NEWS
Update NEWS
Update NEWS
Update NEWS
BFN
BFN
Fixed bug #67715 (php-milter does not build and crashes randomly).
We need to turn off any strict mode here for this warning to show up
Disable restrictions regarding arrays in constants at run-time. For the discussion around it, see the thread on the mailing list: http://www.mail-archive.com/internals@lists.php.net/msg68245.html
Revert "Fix bug #67064 in a BC safe way"
Updated NEWS for #67693
Updated NEWS for #67693
Fixed bug #67693 - incorrect push to the empty array
add missing entry to NEWS
...
Conflicts:
Zend/tests/errmsg_040.phpt
Zend/tests/ns_059.phpt
Zend/zend_language_parser.y
Zend/zend_vm_def.h
ext/openssl/openssl.c
ext/reflection/php_reflection.c
ext/session/session.c
ext/spl/spl_directory.c
ext/spl/spl_iterators.c
ext/sqlite3/sqlite3.c
ext/standard/array.c
For unixODBC, use ODBC version as defined by it (as of v2.2.14 it is 3.5).
This allows us to use newer features like SQL_DESC_OCTET_LENGTH (which
returns the number of bytes required to store the data). This fixes the issue
in #60616. If the newer version is not available, over-allocate to accomodate
4-byte Unicode characters for CHAR and VARCHAR datatypes (and their Wide
counterparts).
version.
Fixed a couple of failing tests.
The ODBC extension did not support WVARCHAR. WVARCHAR ends up being handled by
the default handler where vallen is set by the driver to the actual bytes
needed for the field. If it is larger than default-lrl then the output is
corrupted (reading past the buffer) because the return functions don't expect
that to happen. The patch add support to handle WVARCHAR just like a regular
VARCHAR.
