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 02BFE6FCBF; Tue, 5 Oct 2021 00:52:22 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 02BFE6FCBF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1633384342; bh=fXyNCxReD/nGN0oERMvoTO7VlaZcRtb/fHx7IE8e44M=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=OddmgpJcZnNjs4rBZJcU8prFBWNY6txIWlIGP/rVuZB7pVdqulGG66XRGXbL66XbD QAoqAwf3U3hY2jsKxnwBA1LT9ICCK4rCNSyh8gMm/7XHUV0MBxYfazt2ZRPZJm9sbR lijC1qd98qlNP0011k8vfeg1O+DoG7qZ4vDn9zkU= Received: from smtpng1.i.mail.ru (smtpng1.i.mail.ru [94.100.181.251]) (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 9E6EB6FCBF for ; Tue, 5 Oct 2021 00:52:20 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 9E6EB6FCBF Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1mXVsh-0007Md-UU; Tue, 05 Oct 2021 00:52:20 +0300 To: imeevma@tarantool.org Cc: tarantool-patches@dev.tarantool.org References: Message-ID: Date: Mon, 4 Oct 2021 23:52:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9064ADF4728AA0EE9F29F6F937CFD73092774A1760F25EB43182A05F538085040EA0E0B1C39FD93D3A17749530191211B877C934D486E36D5BCD1920643F9FD49 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE752E71F0C64B7C834EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637367CCE42412B8BE38638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D871995F9E685AD2710B182E7D6D006E1D117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC55B19328CBC4F849A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735201E561CDFBCA1751F28451B159A507268D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B613439FA09F3DCB32089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A213B5FB47DCBC3458834459D11680B505C0B97CAE4A76F82FCFC7A6F13DDAEC25 X-C1DE0DAB: 0D63561A33F958A525699C7466052D8CED29A778FFDFFF4671A19B3DFF3CA7C1D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75B7BFB303F1C7DB4D8E8E86DC7131B365E7726E8460B7C23C X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D347130F804358653A6AA56A02E92DFBE739946697EE7FE257F48CC6722FE9BA0E21239C0DC76B082FD1D7E09C32AA3244CCC7A8106D60D974C0914864075E70741408A6A02710B7304729B2BEF169E0186 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj+1ww+tpaZeqpookEVvGCdA== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D324EF518CC92406395A934D713A645BA3841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v4 02/16] sql: fix possible undefined behavior during cast 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 Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Thanks for the fixes! On 01.10.2021 14:48, imeevma@tarantool.org wrote: > This patch fixes possible undefined behavior during the implicit cast of > INTEGER to DOUBLE. The problem is, if the INTEGER is close enough to > 2^64, it will be cast to 2^64 when it is cast to DOUBLE. Since we have a > check for loss of precision, this will cause this DOUBLE to be cast to > an INTEGER, which will result in undefined behavior since this DOUBLE is > outside the range of INTEGER. > --- > src/box/sql/mem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/box/sql/mem.c b/src/box/sql/mem.c > index 24d6d7dbf..079083fa1 100644 > --- a/src/box/sql/mem.c > +++ b/src/box/sql/mem.c > @@ -682,7 +682,7 @@ uint_to_double_precise(struct Mem *mem) > assert(mem->type == MEM_TYPE_UINT); > double d; > d = (double)mem->u.u; > - if (mem->u.u != (uint64_t)d) > + if (d == (double)UINT64_MAX || mem->u.u != (uint64_t)d) What if uint really was UINT64_MAX? Then you treat its conversion into UINT64_MAX double as an error? Maybe we could simply refuse to convert all ints > 2^53 and <-2^53 (or whatever is the precise int limit in double). All ints above these values will convert 'from time to time' depending on exact values, which does not look reliable anyway.