Some applications check a LDAP link's error code after seeing ldap_bind
fail due to a null byte bind attempt and hence incorrectly receive the
last set error code.
Fix by setting an LDAP error code before returning in this case.
This fixes a bug in libmagic where a cast to 'char' is assumed to result
in sign extension to occur. However, unqualified 'char' is unsigned on
architectures such as ARM, so the cast needs to be to 'signed char'
explicitly.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Some environments, apparently regardless to the freetype version, output 155, while others 156. I guess we can accept both ;)
This reverts commit 592df89027.
Ensure data from OpenSSL internal buffer has been
transfered to PHP stream buffer before a select()
emulation operation is performed
Addresses bug #65137https://bugs.php.net/bug.php?id=65137
Conflicts:
ext/openssl/xp_ssl.c
strtok() is not thread safe, so this will potentially break in
very bad ways if used in ZTS mode.
I'm not sure why gd_strtok_r() exists since it seems to do the
same thing as strtok_r(), but I'll assume it's a portability
decision and do as the Romans do.
* pull-request/772:
Fix failing tests
Patch for bug #67839 (mysqli does not handle 4-byte floats correctly)
Before the patch, a value of 9.99 in a FLOAT column came out of mysqli
as 9.9998998641968. This is because it would naively cast a 4-byte float
into PHP's internal 8-byte double.
To fix this, with GCC we use the built-in decimal support to "up-convert"
the 4-byte float to a 8-byte double.
When that is not available, we fall back to converting the float
to a string and then converting the string to a double. This mimics
what MySQL does.
Before the patch, a value of 9.99 in a FLOAT column came out of mysqli
as 9.9998998641968. This is because it would naively cast a 4-byte float
into PHP's internal 8-byte double.
To fix this, with GCC we use the built-in decimal support to "up-convert"
the 4-byte float to a 8-byte double.
When that is not available, we fall back to converting the float
to a string and then converting the string to a double. This mimics
what MySQL does.
(chained zlib filters silently fail with large amounts of data)
Use the same buffer size zlib uses internally to avoid
Z_DATA_ERROR on massively compressed data
Upstream 463c3bd09b
Notice: this fix don't manage monochrome/monovisual values
but just fix the security issue CVE-2014-2497
failing when trying to load such an image
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.
