Re: glibc qsort() vulnerability - Mailing list pgsql-hackers

From Tom Lane
Subject Re: glibc qsort() vulnerability
Date
Msg-id 1074897.1707417842@sss.pgh.pa.us
Whole thread Raw
In response to Re: glibc qsort() vulnerability  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: glibc qsort() vulnerability
Re: glibc qsort() vulnerability
List pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Thu, Feb 08, 2024 at 02:16:11PM +0100, Mats Kindahl wrote:
>> +/*
>> + * Compare two integers and return -1, 0, or 1 without risking overflow.
>> + *
>> + * This macro is used to avoid running into overflow issues because a simple
>> + * subtraction of the two values when implementing a cmp function for qsort().
>> +*/
>> +#define INT_CMP(lhs,rhs) (((lhs) > (rhs)) - ((lhs) < (rhs)))

> I think we should offer a few different macros, i.e., separate macros for
> int8, uint8, int16, uint16, int32, etc.  For int16, we can do something
> faster like

>     (int32) (lhs) - (int32) (rhs)

> but for int32, we need to do someting more like what's in the patch.

Are we okay with using macros that (a) have double evaluation hazards
and (b) don't enforce the data types being compared are the same?
I think static inlines might be a safer technology.  Perhaps it's
okay given the only expected use is in qsort comparators, but ...

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: glibc qsort() vulnerability
Next
From: Jim Jones
Date:
Subject: Re: Psql meta-command conninfo+