Re: glibc qsort() vulnerability

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: glibc qsort() vulnerability
Дата
Msg-id 1074897.1707417842@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: glibc qsort() vulnerability  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: glibc qsort() vulnerability  (Andres Freund <andres@anarazel.de>)
Re: glibc qsort() vulnerability  (Mats Kindahl <mats@timescale.com>)
Список 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 по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: glibc qsort() vulnerability
Следующее
От: Jim Jones
Дата:
Сообщение: Re: Psql meta-command conninfo+