Both of our own implementations of rint(3) were inconsistent with the
most common behavior of rint() on those platforms that have it: round
to nearest, break ties by rounding to nearest even.
Fixed by leaving just one implementation of rint() in our source tree,
and changing its behavior to match the most common native
implementations on other platforms.
floating point numbers
Some math functions did not check if the result is a valid number
(i.e. neither of +-inf or nan).
Fixed by validating the result where necessary and returning NULL in
case of invalid result.
When calculating the result length of an integer DIV function
the number of decimals was used without checking the result type
first. Thus an uninitialized number of decimals was used for some
types. This caused an excessive amount of memory to be allocated
for the field's buffer and crashed the server.
Fixed by using the number of decimals only for data types that
can have decimals and thus have valid decimals number.
- unsigned flag was not handled correctly for a number of mathematical funcions, which led to incorrect results
- passing large values as the number of decimals to ROUND() resulted in incorrect results and even server crashes in some cases
- reverted the fix and the testcase for bug #10083 as it violates the manual
- fixed some testcases which relied on broken ROUND() behavior
RAND() must accept scalar expressions regardless of their kind.
That includes both constant expressions and expressions that
depend on column values.
When the expression is constant the random seed can be initialized
at compile time.
However when the expression is not constant the random seed must be
initialized at each invocation (while it still can be allocated at
compile time).
Implemented the above rules by extending Item_func_rand::val_real()
to initialize the random seed at the correct place.
Due to the complexity of this change, everything is documented in WL#3565
This patch is the third iteration, it takes into account the comments
received to date.
fix for bug#8461
BUG 8461 - TRUNCATE returns incorrect result if 2nd argument is negative
Reason: Both TRUNCATE/ROUND converts INTEGERS to DOUBLE and back to INTEGERS
Changed the integer routine to work on integers only.
This bug affects 4.1, 5.0 and 5.1
Fixing in 4.1 will need to change the routine to handle different types individually.
5.0 did had different routines for different types already just the INTEGER routine was bad.
