Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
5.5, 10.0, 10.1, 10.2, 10.3, 10.4
-
None
Description
CREATE OR REPLACE TABLE t1 (a BIGINT UNSIGNED, b DOUBLE UNSIGNED, c DECIMAL(30,0) UNSIGNED); |
INSERT INTO t1 VALUES(18446744073709551615,18446744073709551615,18446744073709551615); |
SELECT a, b, c, a << 0, b << 0, c << 0 FROM t1\G |
MariaDB [test]> SELECT a, b, c, a << 0, b << 0, c << 0 FROM t1\G
|
*************************** 1. row ***************************
|
a: 18446744073709551615
|
b: 1.8446744073709552e19
|
c: 18446744073709551615
|
a << 0: 18446744073709551615
|
b << 0: 9223372036854775807
|
c << 0: 18446744073709551615
|
1 row in set, 1 warning (0.00 sec)
|
Notice, the result for `b << 0` is probably wrong.
This happens because Field_double::val_int() does not take into accoung the UNSIGNED flag, while Field_new_decimal does.
Note, this problem is repeatable with any function calling val_int(). The left shift operation is used only for demonstration purposes.