From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 5C3CE6EC5F; Tue, 13 Apr 2021 23:49:43 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 5C3CE6EC5F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1618346983; bh=PrNpqkLVYXUEkidPudPGMonXPIES/qw8cg6EAEkpaSA=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=PTYCNpEfRQKET8dp6wKUU33uMUctzXmKSPRncSX8k7bAx/ZIF0xu+lqq3BInkR95k +YU8Ym68c4t7qSR0nptQj+nLHwbBRL1y7SMeOgonpRKbup3Zflv1h9HSBIqPQFpEvw pq/rGq78HG6LHpu2aRECR59KV6GOLXxCHz3m9bL0= Received: from smtp58.i.mail.ru (smtp58.i.mail.ru [217.69.128.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id EA5DC6EC5F for ; Tue, 13 Apr 2021 23:49:41 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EA5DC6EC5F Received: by smtp58.i.mail.ru with esmtpa (envelope-from ) id 1lWPyf-00040I-1u; Tue, 13 Apr 2021 23:49:41 +0300 Date: Tue, 13 Apr 2021 23:49:39 +0300 To: Vladislav Shpilevoy Message-ID: <20210413204939.GA21144@tarantool.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD92FFCB8E6708E748094FADAEB10E66ADA4C48BE3C291E66DA182A05F53808504052F7620DFF63B9CB4218712FAE4C76F59B43AB744C4E7B12B495DEC89CC9BD3E X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7DF2546A43F668C04EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006375045C080FAAE96148638F802B75D45FF914D58D5BE9E6BC1A93B80C6DEB9DEE97C6FB206A91F05B2B57877CBE4060F11C14FEABF874DBFA33999716826408816D2E47CDBA5A96583C09775C1D3CA48CFE97D2AE7161E217F117882F4460429724CE54428C33FAD30A8DF7F3B2552694AC26CFBAC0749D213D2E47CDBA5A9658378DA827A17800CE78C592797616C97AB9FA2833FD35BB23DF004C90652538430302FCEF25BFAB3454AD6D5ED66289B5278DA827A17800CE7FDE0CF10F4C341CFD32BA5DBAC0009BE395957E7521B51C20BC6067A898B09E4090A508E0FED6299176DF2183F8FC7C06E8EC05BDE27CD4ACD04E86FAF290E2D7E9C4E3C761E06A71DD303D21008E298D5E8D9A59859A8B6B372FE9A2E580EFC725E5C173C3A84C332C16DEEF884694935872C767BF85DA2F004C90652538430E4A6367B16DE6309 X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A2368A440D3B0F6089093C9A16E5BC824A2A04A2ABAA09D25379311020FFC8D4AD709C0CAEBE94681190DBC4D62FA64D32 X-C1DE0DAB: 0D63561A33F958A5F5EE06A131D23623242CC4D4EAFD054ADFD9865BAF0EA59ED59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34C5CF6F4B28551E3F24D236D73DAAA2A97A52185E703DE6FDBD18CE4AA4B7ED40C9EE10FB0AD3017B1D7E09C32AA3244C581C007F5AA8B9450A56E20482B9952B8A6D4CC6FBFAC251FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojnA7/qPBUIXETVqvo9Bxp1w== X-Mailru-Sender: 5C3750E245F362008BC1685FEC6306EDEFF930B08D694DD74218712FAE4C76F5A119395EB3F4142A5105BD0848736F9966FEC6BF5C9C28D97E07721503EA2E00ED97202A5A4E92BF7402F9BA4338D657ED14614B50AE0675 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v5 21/52] sql: introduce bitwise operations for MEM X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mergen Imeev via Tarantool-patches Reply-To: Mergen Imeev Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Thank you for the review! My answers below. On Tue, Apr 13, 2021 at 01:31:39AM +0200, Vladislav Shpilevoy wrote: > Hi! Thanks for the fixes! > > See 2 comments below. > > > diff --git a/src/box/sql/mem.c b/src/box/sql/mem.c > > index eee72a7fe..aeb801c7c 100644 > > --- a/src/box/sql/mem.c > > +++ b/src/box/sql/mem.c > > @@ -624,6 +624,115 @@ mem_rem(const struct Mem *left, const struct Mem *right, struct Mem *result) > > <...> > > > + > > +int > > +mem_shift_right(const struct Mem *left, const struct Mem *right, > > + struct Mem *result) > > +{ > > + if (is_result_null(left, right, result, FIELD_TYPE_INTEGER)) > > + return 0; > > + int64_t a; > > + int64_t b; > > + if (bitwise_prepare(left, right, &a, &b) != 0) > > + return -1; > > + if (b <= -64) > > + result->u.i = 0; > > + else if (b < 0) > > + result->u.i = a << -b; > > + else if (b > 64) > > + result->u.i = a >= 0 ? 0 : -1; > > + else > > + result->u.i = a >> b; > > 1. Right shit has different meaning for negative and positive > numbers. This code produces invalid output: > > tarantool> box.execute('SELECT 9223372036854775808 >> 3') > --- > - metadata: > - name: COLUMN_1 > type: integer > rows: > - [-1152921504606846976] > ... > > The number should have decreased, but it should not have changed > its sign. It should be 1152921504606846976, positive. But I see > the same bug exists on the master branch, even though it had > special handling for negative numbers, which is also broken. > > Is there a ticket for that? Can you fix it right away? > There is one issue about these operations: #5364. I think these bugs shuld be fixed in this issue. > > + result->flags = result->u.i < 0 ? MEM_Int : MEM_UInt; > > + return 0; > > +} > > + > > +int > > +mem_bit_not(const struct Mem *mem, struct Mem *result) > > +{ > > + mem_clear(result); > > + result->field_type = FIELD_TYPE_INTEGER; > > + if ((mem->flags & MEM_Null) != 0) > > + return 0; > > + int64_t i; > > + bool unused; > > + if (sqlVdbeIntValue(mem, &i, &unused) != 0) { > > + diag_set(ClientError, ER_SQL_TYPE_MISMATCH, mem_str(mem), > > + "integer"); > > + return -1; > > + } > > + result->u.i = ~i; > > + result->flags = result->u.i < 0 ? MEM_Int : MEM_UInt; > > 2. What if the original value was positive, and the user also > expected to get a positive result? For example, what if he did > ~CAST(value AS UNSIGNED)? Or is it useless and I am expected to > do CAST(~value as UNSIGNED)? I believe there is no way to get unsigned value more that INT64_MAX. Casts also won't work: tarantool> box.execute('select ~1;') --- - metadata: - name: COLUMN_1 type: integer rows: - [-2] ... tarantool> box.execute('select CAST(~1 AS UNSIGNED);') --- - null - 'Type mismatch: can not convert -2 to unsigned' ...