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.92) (envelope-from ) id 1jHuWX-00032D-4l for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Mar 2020 19:20:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jHuWV-0008PR-LY for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Mar 2020 19:20:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jHuWV-0008Nb-CR for pgsql-hackers@lists.postgresql.org; Fri, 27 Mar 2020 19:20:07 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jHuWT-0006hu-6s for pgsql-hackers@lists.postgresql.org; Fri, 27 Mar 2020 19:20:07 +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 02RJJxIq020651; Fri, 27 Mar 2020 15:19:59 -0400 From: Tom Lane To: "Daniel Verite" cc: "Ashutosh Bapat" , "movead.li@highgo.ca" , "pgsql-hackers" Subject: Re: A bug when use get_bit() function for a long bytea string In-reply-to: <9087da0f-f048-4cd3-a55c-1c03adea5a02@manitou-mail.org> References: <9087da0f-f048-4cd3-a55c-1c03adea5a02@manitou-mail.org> Comments: In-reply-to "Daniel Verite" message dated "Fri, 27 Mar 2020 18:58:44 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20649.1585336799.1@sss.pgh.pa.us> Date: Fri, 27 Mar 2020 15:19:59 -0400 Message-ID: <20650.1585336799@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk "Daniel Verite" writes: > So aside from the integer overflow bug, isn't there the issue that the > "offset" argument of get_bit() and set_bit() should have been an > int8 in the first place? Good point, but a fix for that wouldn't be back-patchable. It does suggest that we should just make all the internal logic use int8 for these values (as the solution to the overflow issue), and then in HEAD only, adjust the function signatures so that int8 can be passed in. regards, tom lane