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 1gQLL6-00014l-3h for pgsql-bugs@arkaria.postgresql.org; Fri, 23 Nov 2018 23:58:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gQLL4-0001HI-Lz for pgsql-bugs@arkaria.postgresql.org; Fri, 23 Nov 2018 23:58:22 +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 1gQLL4-0001HB-C6 for pgsql-bugs@lists.postgresql.org; Fri, 23 Nov 2018 23:58:22 +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 1gQLKx-0004oL-LI for pgsql-bugs@lists.postgresql.org; Fri, 23 Nov 2018 23:58:21 +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 wANNwEou015333; Fri, 23 Nov 2018 18:58:14 -0500 From: Tom Lane To: Andrew Gierth cc: victor@magic.io, 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: <15115.1543017152@sss.pgh.pa.us> 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> Comments: In-reply-to Tom Lane message dated "Fri, 23 Nov 2018 18:52:32 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15331.1543017494.1@sss.pgh.pa.us> Date: Fri, 23 Nov 2018 18:58:14 -0500 Message-ID: <15332.1543017494@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > Andrew Gierth writes: >> if (num < (float4)INT_MIN || num >= -(float4)INT_MIN || ... > Meh. Seems to me that's relying on pretty much the same assumptions > and throwing in an extra dollop of obscurantism on top. mmm ... but on the other hand, it means we don't need to write the test differently depending on whether we think INTxx_MAX will get rounded. So that's worth something. regards, tom lane