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 0FB2B6EC5F; Thu, 15 Apr 2021 02:10:46 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 0FB2B6EC5F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1618441846; bh=tdJRwIsLnTX3mPu+8/24lS9lBe/umcgkY8LEWEaVHNU=; h=To:References:Date:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=SIotdyMtbYz0Z5ysq+CoNU2YKYVLGqhUymnzMTCex2ZKuP8ba69QyDAc27ZvWWNLL f3q7YJdauEVRhA7D8UNOQ/FKmmC796C2YaO6TPMss++fiUxMpTYly0REsglKn2HHfi zxRRb43ldBueQZuWkgiS+l27XwAfzf7l5B933fDI= Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 CF6E26EC5F for ; Thu, 15 Apr 2021 02:10:44 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org CF6E26EC5F Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1lWoeh-0002Mq-TY; Thu, 15 Apr 2021 02:10:44 +0300 To: Mergen Imeev References: <25bd849d8ebd45d3865770f1c4c6fc0c02d53d6a.1617984948.git.imeevma@gmail.com> <58d97dd1-7090-3c2b-10c6-cdf6f5699bbc@tarantool.org> <20210413170649.GA193613@tarantool.org> Message-ID: <90f8b51d-ef04-0f7f-431f-87a65f89a9d8@tarantool.org> Date: Thu, 15 Apr 2021 01:10:42 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <20210413170649.GA193613@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD92FFCB8E6708E7480BE79914FF86F9151AC38CC435EA4A654182A05F538085040ECBBB53921E80D8547F5A25A0F1BE813CEF1082BAE1A8EB4567CDDC7915221D6 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F4E79F226F99D4DDEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637AAF0FBE7E77B7ED78638F802B75D45FF914D58D5BE9E6BC1A93B80C6DEB9DEE97C6FB206A91F05B28A3414D7C8A96150BBD72913FECE0C5D50D7F87C0C4C56F2D2E47CDBA5A96583C09775C1D3CA48CF4964A708C60C975A117882F4460429724CE54428C33FAD30A8DF7F3B2552694AC26CFBAC0749D213D2E47CDBA5A9658378DA827A17800CE77E7E81EEA8A9722B8941B15DA834481F9449624AB7ADAF372E808ACE2090B5E1725E5C173C3A84C3C5EA940A35A165FF2DBA43225CD8A89F83C798A30B85E16BCE5475246E174218B5C8C57E37DE458BEDA766A37F9254B7 X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A2AD77751E876CB595E8F7B195E1C97831A33BB97BE06084F245A0E006394C2ED0 X-C1DE0DAB: 0D63561A33F958A5A767EBA98489B2EBA1FB21D3AB0A782F1A7FA1A3B12910A5D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D346840168BCAD8054E298C246F2CEAD1A1B237358AF6D4C89DE02EEF118DB241D2F5ABC26C7D7067D11D7E09C32AA3244C799F8A4993E0337595D5552395BFCEBD9CA7333006C390A0FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojrcJA+pXcDumeMuyi8jEmOw== X-Mailru-Sender: 689FA8AB762F73936BC43F508A06382261C27EFB5C275540C3576EBB8BA2E3823841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v5 19/52] sql: introduce arithmetic 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: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Thanks for the fixes! >>> diff --git a/src/box/sql/mem.c b/src/box/sql/mem.c >>> index 2d76ef88d..859e337aa 100644 >>> --- a/src/box/sql/mem.c >>> +++ b/src/box/sql/mem.c >>> @@ -390,6 +390,240 @@ mem_concat(struct Mem *a, struct Mem *b, struct Mem *result) >>> + >>> +static int >>> +get_number(const struct Mem *mem, struct sql_num *number) >>> +{ >>> + if ((mem->flags & MEM_Real) != 0) { >>> + number->d = mem->u.r; >>> + number->type = MEM_Real; >>> + return 0; >>> + } >>> + if ((mem->flags & MEM_Int) != 0) { >>> + number->i = mem->u.i; >>> + number->type = MEM_Int; >>> + number->is_neg = true; >>> + return 0; >>> + } >>> + if ((mem->flags & MEM_UInt) != 0) { >>> + number->u = mem->u.u; >>> + number->type = MEM_UInt; >>> + number->is_neg = false; >>> + return 0; >>> + } >>> + if ((mem->flags & (MEM_Str | MEM_Blob)) == 0) >>> + return -1; >>> + if ((mem->flags & MEM_Subtype) != 0) >>> + return -1; >>> + if (sql_atoi64(mem->z, &number->i, &number->is_neg, mem->n) == 0) { >>> + number->type = number->is_neg ? MEM_Int : MEM_UInt; >>> + /* >>> + * The next line should be removed along with the is_neg field >>> + * of struct sql_num. The integer type tells us about the sign. >>> + * However, if it is removed, the behavior of arithmetic >>> + * operations will change. >>> + */ >>> + number->is_neg = (mem->flags & MEM_Int) != 0; >> >> I don't understand that. How is it possible it mismatches the >> value returned from sql_atoi64()? And why isn't it just 'false' then? >> Because a few lines above you already checked (mem->flags & MEM_Int) != 0 >> and it was false. >> > Not exactly right. For example: > > tarantool> box.execute([[SELECT '-5' + 2;]]) > --- > - metadata: > - name: COLUMN_1 > type: integer > rows: > - [18446744073709551613] > ... > > As you see, this is wrong. This is due to the fact, that MEM of type string do > not have MEM_Int set. Even though this is wrong, it is expected behaviour. I > created an issue for this: #5756. Since I didn't want to change this behaviour, > I added is_neg field to struct sql_num. This is clearly a hack and should be > fixed. But that does not answer the second part of my question - why can't I set it to false here always? ==================== @@ -286,7 +286,7 @@ get_number(const struct Mem *mem, struct sql_num *number) * However, if it is removed, the behavior of arithmetic * operations will change. */ - number->is_neg = (mem->flags & MEM_Int) != 0; + number->is_neg = false; return 0; } ==================== Because (mem->flags & MEM_Int) == 0, otherwise it would return earlier above. Also 'is_neg' is not used at all now in all places where get_number() is called. At least in this commit. I would propose to add it in the commit which needs it or remove it then now.