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 0DD3C6EC5F; Tue, 13 Apr 2021 20:06:53 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 0DD3C6EC5F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1618333613; bh=OgkoJ+2M2l5z7LYqtSi5JvtRtszuG9eIZxSGRyh0OFk=; 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=f1IXAjHdUV8BmNXjOIwEfUmo5xN2b3mxnjog9xX+NcV/McXBDKaP6VyInQWSD+KU/ yb8/KyzabffBltVxFc5+2ZxbiWN4Zk/kc5gpE+F3mJOGHqnJJR+1dGBYdfYKB42nCf bw+Mn5Bv+zOocYCN/tgoQzinY6wxC3+5RNOrjvCA= Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (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 30F5A6EC5F for ; Tue, 13 Apr 2021 20:06:51 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 30F5A6EC5F Received: by smtpng2.m.smailru.net with esmtpa (envelope-from ) id 1lWMV0-0000V1-AY; Tue, 13 Apr 2021 20:06:50 +0300 Date: Tue, 13 Apr 2021 20:06:49 +0300 To: Vladislav Shpilevoy Message-ID: <20210413170649.GA193613@tarantool.org> References: <25bd849d8ebd45d3865770f1c4c6fc0c02d53d6a.1617984948.git.imeevma@gmail.com> <58d97dd1-7090-3c2b-10c6-cdf6f5699bbc@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <58d97dd1-7090-3c2b-10c6-cdf6f5699bbc@tarantool.org> X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD92FFCB8E6708E7480257C85EA0BB7A95D5E28B957962BB550182A05F538085040ED805C96EAC2FF7BEE279B76EF27B699D660CC65E7EBB3BF364074141D0F981B X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7EB05B7739F1E6D56EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006378B49D47CE295E66E8638F802B75D45FF914D58D5BE9E6BC1A93B80C6DEB9DEE97C6FB206A91F05B2CB75D0AAED87895F7D5B1C87BC2B90B950D7F87C0C4C56F2D2E47CDBA5A96583C09775C1D3CA48CF17B107DEF921CE79117882F4460429724CE54428C33FAD30A8DF7F3B2552694AC26CFBAC0749D213D2E47CDBA5A9658378DA827A17800CE77A825AB47F0FC8649FA2833FD35BB23DF004C906525384302BEBFE083D3B9BA73A03B725D353964B0B7D0EA88DDEDAC722CA9DD8327EE4930A3850AC1BE2E7354E672349037D5FA5C4224003CC83647689D4C264860C145E X-C1DE0DAB: 0D63561A33F958A549CF37BBA6C9CC97000DD4ED2830419B7203AAB3B85EBC0AD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3498910055B812BD9C5D9120ECBA37CC155FAE803430FA2A11331F4EF428E6EFC5963909BA1B39F7011D7E09C32AA3244CBCF87E6880E692AEDFA1AE764C4772389CA7333006C390A0FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojnA7/qPBUIXEjfMg1d9QmHg== X-Mailru-Sender: 689FA8AB762F73936BC43F508A063822BF4814ABE18D5172705231EC0FC8B36283D72C36FC87018B9F80AB2734326CD2FB559BB5D741EB96352A0ABBE4FDA4210A04DAD6CC59E33667EA787935ED9F1B 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: 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 Sun, Apr 11, 2021 at 08:13:27PM +0200, Vladislav Shpilevoy wrote: > Good job on the fixes! > > >> The names could be mem_arith_plus(), mem_arith_mul(), mem_arith_minus(), > >> etc. > > Fixed. I named new functions mem_add(), mem_sub(), mem_mul(), mem_div() and > > mem_rem(). Each of them simpler than this function. > > The last operation is called modulo. Usually shortened to mod. But I see > we already use 'rem' in some other place, and in the token name. Up to you. > I will leave it as it is for now. This function should be fixed at some point (see comments in its body). > See 1 comment below. > > > 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. > > + return 0; > > + } > > + if (sqlAtoF(mem->z, &number->d, mem->n) != 0) { > > + number->type = MEM_Real; > > + return 0; > > + } > > + return -1; > > +}