Re: glibc qsort() vulnerability

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: glibc qsort() vulnerability
Дата
Msg-id 20240212213130.jp5vwotwazypaaez@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: glibc qsort() vulnerability  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: glibc qsort() vulnerability  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
Hi,

On 2024-02-12 14:51:38 -0600, Nathan Bossart wrote:
> On Mon, Feb 12, 2024 at 06:09:06PM +0100, Mats Kindahl wrote:
> > Here are the two fixed patches.
> 
> These patches look pretty good to me.  Barring additional feedback, I'll
> plan on committing them in the next few days.

One thing that's worth checking is if this ends up with *worse* code when the
comparators are inlined. I think none of the changed comparators will end up
getting used with an inlined sort, but ...

The reason we could end up with worse code is that when inlining the
comparisons would make less sense for the compiler. Consider e.g.
    return DO_COMPARE(a, b) < 0 ?
        (DO_COMPARE(b, c) < 0 ? b : (DO_COMPARE(a, c) < 0 ? c : a))
        : (DO_COMPARE(b, c) > 0 ? b : (DO_COMPARE(a, c) < 0 ? a : c));

With a naive implementation the compiler will understand it only cares about
a < b, not about the other possibilities. I'm not sure that's still true with
the more complicated optimized version.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Luzanov
Дата:
Сообщение: Re: Things I don't like about \du's "Attributes" column
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Fix a typo in pg_rotate_logfile