From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Andres Freund <andres@anarazel.de>, Mats Kindahl <mats@timescale.com>,
        Thomas Munro <thomas.munro@gmail.com>,
        Heikki Linnakangas <hlinnaka@iki.fi>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: glibc qsort() vulnerability
In-reply-to: <20240208200737.GA504276@nathanxps13>
References: <20240208004207.aoyrtv577nmhrivy@awork3.anarazel.de>
 <20240208015211.GA445153@nathanxps13>
 <20240208020637.3irwi5vph4fbxw2f@awork3.anarazel.de>
 <CA+hUKGLbC4O56rtFM69Tx6StT3PcVio9K2GisjZp=z6O20Q3sw@mail.gmail.com>
 <CA+hUKGJaOM5ULeXboxV+fGkU-pYHotL5A10hYxdu8_kwRcVEgQ@mail.gmail.com>
 <20240208025620.GC445153@nathanxps13>
 <CA+14424k0MbdkJuSSLrr1==PYK+oL5Gtq7siTsMgCs+KcCrEvA@mail.gmail.com>
 <20240208183835.GA503311@nathanxps13> <1074897.1707417842@sss.pgh.pa.us>
 <20240208195954.vlpoii4ftoow2of4@awork3.anarazel.de>
 <20240208200737.GA504276@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Thu, 08 Feb 2024 14:07:37 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1242425.1707424769.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 08 Feb 2024 15:39:29 -0500
Message-ID: <1242426.1707424769@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1242426.1707424769%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Thu, Feb 08, 2024 at 11:59:54AM -0800, Andres Freund wrote:
>> I'd put these static inlines into common/int.h. I don't think this is c=
ommon
>> enough to warrant being in c.h. Probably also doesn't hurt to have a no=
t quite
>> as generic name as INT_CMP, I'd not be too surprised if that's defined =
in some
>> library.
>> =

>> I think it's worth following int.h's pattern of including [s]igned/[u]n=
signed
>> in the name, an efficient implementation for signed might not be the sa=
me as
>> for unsigned. And if we use static inlines, we need to do so for correc=
t
>> semantics anyway.

> Seems reasonable to me.

+1 here also.

			regards, tom lane