Revert unintentional docblock change
It looks like commit dd8e59da8f
introduced an unintended docbloc change. I have reverted this
change in this commit.
Drop use of php memory allocators as this raise various conflicts
with other extensions and libraries which use libgmp.
No other solution found.
We cannot for ensure correct use of allocator with shared lib.
Some memory can allocated before php init
Some memory can be freed after php shutdown
Known broken run cases
- php + curl + gnutls + gmp
- mod_gnutls + mod_php + gnutls + gmp
- php + freetds + gnutls + gmp
- php + odbc + freetds + gnutls + gmp
- php + php-mapi (zarafa) + gnutls + gmp
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.
