From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2D6B72A3FB for ; Mon, 1 Apr 2019 16:44:09 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUBPGXx6PXoW for ; Mon, 1 Apr 2019 16:44:09 -0400 (EDT) Received: from smtp44.i.mail.ru (smtp44.i.mail.ru [94.100.177.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id D21572A3EF for ; Mon, 1 Apr 2019 16:44:08 -0400 (EDT) From: Stanislav Zudin Subject: [tarantool-patches] Re: [PATCH 13/13] sql: support -2^63 .. 2^64-1 integer type References: Message-ID: <897b6db3-9d53-431b-c38c-1f151cce66e2@tarantool.org> Date: Mon, 1 Apr 2019 23:44:06 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org, "n.pettik" On 25.03.2019 18:25, n.pettik wrote: > Merge this patch with the main one in your patch-set. > Also, please add sufficient number of tests verifying that > INT in a range of [2^63, 2^64 - 1] is working without as designed > >> Closes #3810 >> --- >> test/sql-tap/func.test.lua | 6 +++--- >> test/sql-tap/hexlit.test.lua | 6 ++++-- >> test/sql/gh-2347-max-int-literals.result | 2 +- >> test/sql/integer-overflow.result | 10 +++++----- >> test/sql/iproto.result | 11 +++++++---- >> test/sql/iproto.test.lua | 5 ++--- >> 6 files changed, 22 insertions(+), 18 deletions(-) >> >> diff --git a/test/sql-tap/func.test.lua b/test/sql-tap/func.test.lua >> index 889fc5867..8e75f9c89 100755 >> --- a/test/sql-tap/func.test.lua >> +++ b/test/sql-tap/func.test.lua >> @@ -1591,14 +1591,14 @@ test:do_execsql_test( >> -- >> }) >> >> -test:do_catchsql_test( >> +test:do_execsql_test( >> "func-18.12", >> [[ >> INSERT INTO t6 VALUES(3, 1<<62); >> SELECT sum(x) - ((1<<62)*2.0+1) from t6; >> ]], { >> -- >> - 1, "integer overflow" >> + 0 > > > tarantool> SELECT sum(x) from t6; > --- > - - [9223372036854775809] > ... > > tarantool> SELECT ((1<<62)*2.0+1) from t6; > --- > - - [9223372036854775808] > - [9223372036854775808] > - [9223372036854775808] > … > > So, how it could be that SELECT sum(x) - ((1<<62)*2.0+1) is 0? > The "func-18.12" uses data inserted in "func-18.10". The "(1<<62)" was inserted twice. tarantool> box.sql.execute("SELECT * from t6;") --- - - [1, 1] - [2, 4611686018427387904] - [3, 4611686018427387904] ... tarantool> box.sql.execute("SELECT sum(x) from t6;") --- - - [9223372036854775809] ... tarantool> box.sql.execute("SELECT sum(x) - ((1<<62)*2.0+1) from t6;") --- - - [0] ... This test is definitely correct. > > What is more, I see this: > > tarantool> SELECT typeof(sum(x)) from t6; > --- > - - ['null'] > … > > Which is obviously wrong. This was a bug. Fixed. > > >> diff --git a/test/sql-tap/hexlit.test.lua b/test/sql-tap/hexlit.test.lua >> index 158eda73b..1597d4b8a 100755 >> --- a/test/sql-tap/hexlit.test.lua >> +++ b/test/sql-tap/hexlit.test.lua >> @@ -1,6 +1,6 @@ >> #!/usr/bin/env tarantool >> test = require("sqltester") >> -test:plan(128) >> +test:plan(130) >> >> --!./tcltestrunner.lua >> -- 2014-07-23 >> @@ -91,7 +91,9 @@ hexlit1(160, "0X1000000000000000", 1152921504606846976LL) >> hexlit1(161, "0x2000000000000000", 2305843009213693952LL) >> hexlit1(162, "0X4000000000000000", 4611686018427387904LL) >> hexlit1(163, "0x8000000000000000", -9223372036854775808LL) >> -hexlit1(164, "0XFFFFFFFFFFFFFFFF", -1) >> +hexlit1(164, "0x8000000000000000", 9223372036854775808ULL) >> +hexlit1(165, "0x8000000000000001", 9223372036854775809ULL) >> +hexlit1(166, "0XFFFFFFFFFFFFFFFF", 18446744073709551615ULL) >> for n = 1, 0x10 -1, 1 do >> hexlit1("200."..n..".1", "0X"..string.format("%03X",n), n) >> hexlit1("200."..n..".2", "0x"..string.format("%03X",n), n) >> diff --git a/test/sql/gh-2347-max-int-literals.result b/test/sql/gh-2347-max-int-literals.result >> index c289a80fe..e6f78d244 100644 >> --- a/test/sql/gh-2347-max-int-literals.result >> +++ b/test/sql/gh-2347-max-int-literals.result >> @@ -20,7 +20,7 @@ box.sql.execute("select (-9223372036854775808)") >> ... >> box.sql.execute("select (9223372036854775808)") >> --- >> -- error: 'oversized integer: 9223372036854775808' >> +- - [9223372036854775808] > > Please, make these test check that overflow error is handled, > not simply fixing result file. > > Done. >