Date: Fri, 16 Aug 2024 13:35:01 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Joseph Koshakow <koshy44@gmail.com>,
	jian he <jian.universality@gmail.com>,
	Heikki Linnakangas <hlinnaka@iki.fi>,
	Matthew Kim <matthewkmkim@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Andres Freund <andres@anarazel.de>
Subject: Re: Remove dependence on integer wrapping
Message-ID: <Zr-b1c6x-Yf31TCZ@nathan>
References: <875ad3ec-f216-487e-baad-cdbaf32c1fcf@iki.fi>
 <ZrznaJTIOPgSjEJ7@nathan>
 <CAAvxfHc2Smk92cJX4aUju1AdW_RpNN8csEj5rvf29b-YFHRmfQ@mail.gmail.com>
 <Zrz0Zv4PVFxieEii@nathan>
 <CACJufxH-uLR5SnnmVbGYj7Oy90zF_pYV3G_HxfbJ6Lu3XKGXxQ@mail.gmail.com>
 <Zr5M3KxOZlEZRZIN@nathan>
 <Zr50ZpSyrBx0EHfR@nathan>
 <CAAvxfHfkHS1n0+wMbtKwj6_GE6+aSJ9JjnsCOOdZPhTKRs-Yhw@mail.gmail.com>
 <Zr-DwBxep-IaayQF@nathan>
 <bfff906f-300d-81ea-83b7-f2c93845e7f2@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <bfff906f-300d-81ea-83b7-f2c93845e7f2@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/Zr-b1c6x-Yf31TCZ%40nathan>
Precedence: bulk

On Fri, Aug 16, 2024 at 09:00:00PM +0300, Alexander Lakhin wrote:
> Sp it looks like jsonb_array_element_text() still needs the same
> treatment as jsonb_array_element().

D'oh.  I added a test for that but didn't actually fix the code.  I think
we just need something like the following.

diff --git a/src/backend/utils/adt/jsonfuncs.c b/src/backend/utils/adt/jsonfuncs.c
index 1f8ea51e6a..69cdd84393 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils/adt/jsonfuncs.c
@@ -990,7 +990,7 @@ jsonb_array_element_text(PG_FUNCTION_ARGS)
     {
         uint32      nelements = JB_ROOT_COUNT(jb);

-        if (-element > nelements)
+        if (pg_abs_s32(element) > nelements)
             PG_RETURN_NULL();
         else
             element += nelements;

> Moreover, I tried to use "-ftrapv" on 32-bit Debian and came across
> another failure:
> select '9223372036854775807'::int8 * 2147483648::int8;
> server closed the connection unexpectedly
> ...
> #4  0xb722226a in __GI_abort () at ./stdlib/abort.c:79
> #5  0x004cb2e1 in __mulvdi3.cold ()
> #6  0x00abe7ab in pg_mul_s64_overflow (a=9223372036854775807, b=2147483648, result=0xbff1da68)
>     at ../../../../src/include/common/int.h:264
> #7  0x00abfbff in int8mul (fcinfo=0x14d9d04) at int8.c:496
> #8  0x00782675 in ExecInterpExpr (state=0x14d9c4c, econtext=0x14da15c, isnull=0xbff1dc3f) at execExprInterp.c:765

Hm.  It looks like that is pointing to __builtin_mul_overflow(), which
seems strange.

> #6  0x00005576cf627c68 in bms_singleton_member (a=0x5576d09f7fb0) at bitmapset.c:691
> 691                             if (result >= 0 || HAS_MULTIPLE_ONES(w))

At a glance, this appears to be caused by the RIGHTMOST_ONE macro:

	#define RIGHTMOST_ONE(x) ((signedbitmapword) (x) & -((signedbitmapword) (x)))

-- 
nathan