From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp39.i.mail.ru (smtp39.i.mail.ru [94.100.177.99]) (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 DF751469710 for ; Mon, 8 Jun 2020 14:22:28 +0300 (MSK) Date: Mon, 8 Jun 2020 14:22:13 +0300 From: Alexander Turenko Message-ID: <20200608112213.hf4fjwwikct74qab@tkn_work_nb> References: <20200605140125.25329-1-sergepetrenko@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200605140125.25329-1-sergepetrenko@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] decimal: fix build with GCC 10 List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Serge Petrenko Cc: tarantool-patches@dev.tarantool.org The patch itself is okay. On Fri, Jun 05, 2020 at 05:01:25PM +0300, Serge Petrenko wrote: > GCC 10 produces the following error: > cc1: warning: function may return address of local variable [-Wreturn-local-addr] > > Fix it. It would be good to mention whether it is a real problem or false-positive. (The patch is already pushed, so this comment is just for information.) As I see, we actually return a data on the stack before the patch, so it worth to mention the bugfix in the release notes. Kirill, can you add this? @ChangeLog - Fix use-after-scope when converting a decimal number to int64_t or uint64_t that may lead to undefined behaviour in tuple comparators and so in behaviour of space indices (part of gh-4966). (Serge, correct me if I'm wrong here.) BTW, are those hints pesisted for vinyl? Can we get wrong results even after upgrade? WBR, Alexander Turenko.