Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gQMy4-0006Zm-6N for pgsql-bugs@arkaria.postgresql.org; Sat, 24 Nov 2018 01:42:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gQMy1-0003Kd-J7 for pgsql-bugs@arkaria.postgresql.org; Sat, 24 Nov 2018 01:42:41 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gQMy1-0003KW-8v for pgsql-bugs@lists.postgresql.org; Sat, 24 Nov 2018 01:42:41 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gQMxy-00077S-8a for pgsql-bugs@lists.postgresql.org; Sat, 24 Nov 2018 01:42:39 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id wAO1gaXM018152; Fri, 23 Nov 2018 20:42:36 -0500 From: Tom Lane To: Victor Petrovykh cc: andrew@tao11.riddles.org.uk, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #15519: Casting float4 into int4 gets the wrong sign instead of "integer out of range" error In-reply-to: References: <15519-4fc785b483201ff1@postgresql.org> <874lc7sb1a.fsf@news-spur.riddles.org.uk> <13162.1543014227@sss.pgh.pa.us> <87zhtzqs9o.fsf@news-spur.riddles.org.uk> <15115.1543017152@sss.pgh.pa.us> <87va4nqr1a.fsf@news-spur.riddles.org.uk> Comments: In-reply-to Victor Petrovykh message dated "Fri, 23 Nov 2018 20:16:23 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18150.1543023756.1@sss.pgh.pa.us> Date: Fri, 23 Nov 2018 20:42:36 -0500 Message-ID: <18151.1543023756@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Victor Petrovykh writes: > Am I missing something in thinking that the cast of a float to int should > produce an error if the sign of the original value doesn't match the sign > of the cast result? Well, yeah, our traditional way of coding this overflow check would probably have compared the sign of the result to the sign of the input, but (a) we'd still have needed some ad-hoc range check to avoid getting fooled by inputs large enough to have wrapped around an even number of times, and (b) this approach depends on the compiler not taking any liberties based on an assumption that the program doesn't provoke integer overflow. (b) gets more worrisome with each year that goes by, because the compiler guys keep finding ever-more-creative ways to break your code if it violates C-spec semantics. So we really want to write a test that will fail exactly when the integer coercion would overflow, not do the coercion and then check to see if it overflowed. regards, tom lane