Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sUsc8-006OtU-JZ for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jul 2024 18:45:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sUsc6-003cyp-MO for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jul 2024 18:45:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sUsc6-003cyh-CS for pgsql-hackers@lists.postgresql.org; Fri, 19 Jul 2024 18:45:54 +0000 Received: from mail-io1-xd32.google.com ([2607:f8b0:4864:20::d32]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sUsc4-000PjU-CL for pgsql-hackers@lists.postgresql.org; Fri, 19 Jul 2024 18:45:53 +0000 Received: by mail-io1-xd32.google.com with SMTP id ca18e2360f4ac-8036ce66134so85116539f.3 for ; Fri, 19 Jul 2024 11:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721414751; x=1722019551; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IbILR0ieCfiUVvGvg6/RdWpMaePEJUGKg6c3kPK8xdA=; b=Y1xQh4w5UCokiP1o5pNxLkStkU8Sc/uDsw4A85ERjMVNbkB09Jrd6xmSoPh13jLUxR rROYn9W2BFdsBUAoUShq85R0wntP7+GoUYzRu76k5P7m93WZ8NVehI3lqpsavNUVTXSU ZZ6TWRJo4CFycL3ByiwCOLeEednhmCBpHLKgDNXtEz20/bd2DPVyV8bg3E5YFvw7Ws6S sFFkbZME0vZs1NafEzct15erI4KxuzHIz5JkgnKR8owVfK6GhwTZ7ItCaInnYP+gZvWu MUSm9MLpgTxTBQ0MZThu6dMFJSZDiRLjbuj4XQJVG+/0tuccOpbF23gSj9Kc5lH/bzu/ Qs0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721414751; x=1722019551; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IbILR0ieCfiUVvGvg6/RdWpMaePEJUGKg6c3kPK8xdA=; b=eMumm+zBtcQU9iORJAkFAwGSAEF2k3yFg27Hi7mdeUVY4zVACDSEPtHotWZQADrxuK N1xt1Qh/i61Z1Id/VTx3gemmpTf/ZNpcpdMIubFXE9FU4/r01bOv//IEP6fiOuWTFzhB UokdRyFlFaUSlNcabFZuq93gbjPsSfYY0EUoKnwq/0cXJnt9TOiQC2+OyKMEvBRgtRZl uRlC8jpYK+bPO98J57xifZwFjzPBdkvfVyQZorPMbt0nGWZviXb+qUubJ3UQaId/02d6 WeFPaFWugL58n7ULZbs9IszXr2BEXPOgit7wTpL/pppG+e7MAt7i6nrFuUFBvaUuy6Ej tKjQ== X-Forwarded-Encrypted: i=1; AJvYcCX0HBAhbzaS4pjuttnOO5X+KxFAig+/efu1iLgR3RrRajOTyy0UGznWxXU+ZPoY8RkiRvLSfKGhyjf2zghC+LUP33TBcLxlR71vJZZTViC5sPuQ X-Gm-Message-State: AOJu0Yx5WGVJHFPy6CbErc014zMcqTg2ge3XfYFlnrmldlt9A6ySfCQ2 wOOigedGUjp9CFLSrmcb+p9RaUyY5JZZlzqgM7na+nchKUTmfDijBS28Yw== X-Google-Smtp-Source: AGHT+IFMqjIJBjzpujP0KDuZ/CR4ZjlzC54tTk72yNw++4qFPE9DsrRDb72xlmEN+RGChfn0tQ6MZA== X-Received: by 2002:a05:6602:15d5:b0:804:b327:52d5 with SMTP id ca18e2360f4ac-81710040d2amr1228841439f.4.1721414751417; Fri, 19 Jul 2024 11:45:51 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-819aba13e14sm61345939f.2.2024.07.19.11.45.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jul 2024 11:45:51 -0700 (PDT) Date: Fri, 19 Jul 2024 13:45:49 -0500 From: Nathan Bossart To: Joseph Koshakow Cc: jian he , Alexander Lakhin , Tom Lane , PostgreSQL Hackers , Andres Freund Subject: Re: Remove dependence on integer wrapping Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I took a look at 0003. + /* dim[i] = 1 + upperIndx[i] - lowerIndx[i]; */ + if (pg_add_s32_overflow(1, upperIndx[i], &dim[i])) + ereport(ERROR, + (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED), + errmsg("array upper bound is too large: %d", + upperIndx[i]))); + if (pg_sub_s32_overflow(dim[i], lowerIndx[i], &dim[i])) + ereport(ERROR, + (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED), + errmsg("array size exceeds the maximum allowed (%d)", + (int) MaxArraySize))); I think the problem with fixing it this way is that it prohibits more than is necessary. For example, doing the subtraction first might prevent the addition from overflowing, and doing the addition first can prevent the subtraction from overflowing. Granted, this is probably not really worth worrying about too much, but we're already dealing with "absurd slice ranges," so we might as well set an example for elsewhere. An easy way to deal with this problem is to first perform the calculation with everything cast to an int64. Before setting dim[i], you'd check that the result is in [PG_INT32_MIN, PG_INT32_MAX] and fail if needed. int64 newdim; ... newdim = (int64) 1 + (int64) upperIndx[i] - (int64) lowerIndx[i]; if (unlikely(newdim < PG_INT32_MIN || newdim > PG_INT32_MAX)) ereport(ERROR, ... dim[i] = (int32) newdim; -- nathan