and #68657 (Reading 4 byte floats with Mysqli and libmysqlclient
has rounding errors).
The patch removes support for Decimal floating point numbers and
now defaults to using similar logic as what libmysqlclient does:
convert a 4 byte floating point number into a string, and then the
string into a double. The quirks of MySQL are maintained as seen in
Field_Float::val_str()
gcc (i686-apple-darwin10-gcc-4.2.1) on OS X cannot link fixed-width
decimals and fails with undefined symbols errors like ___extendsddf.
If configure used gcc for compiling it would notice and mark the
feature HAVE_DECIMAL_FP_SUPPORT as unsupported.
But configure seems to use cc (i686-apple-darwin10-llvm-gcc-4.2)
instead, which doesn't support fixed-width decimals either, but the
code compiles and links just fine. I suspect it may have something
to do with the llvm backend printed in the version.
Lacking the time to debug this further, the patch fixes the issue by
checking the expected output when fixed-width decimal support is
present and correctly implemented.
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.
There are situations where mysqlnd dupliates zvals while freeing result
sets. If the memory_limit is reached during this operation the engine
will bailout. This patch makes sure that a later attempt (during
RSHIUTDOWN) won't cause a double free, instead we rely on the engine to
free emalloc()ed memory after bailout.
