Re: Fix overflow in pg_size_pretty

Поиск
Список
Период
Сортировка
От Joseph Koshakow
Тема Re: Fix overflow in pg_size_pretty
Дата
Msg-id CAAvxfHcq=7NiUBgdGD1DeZcG0tVVxbpq8n20MbrWj=1k3NE8mw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fix overflow in pg_size_pretty  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Fix overflow in pg_size_pretty
Список pgsql-hackers
On Sat, Jul 27, 2024 at 8:00 PM David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Sun, 28 Jul 2024 at 11:06, Joseph Koshakow <koshy44@gmail.com> wrote:
>> > + uint64 usize = size < 0 ? (uint64) (-size) : (uint64) size;
>>
>> I think that the explicit test for PG_INT64_MIN is still required. If
>> `size` is equal to PG_INT64_MIN then `-size` will overflow. You end up
>> with the correct behavior if `size` wraps around, but that's only
>> guaranteed on platforms that support the `-fwrapv` flag.
>
> What if we spelt it out the same way as pg_lltoa() does?
>
> i.e: uint64 usize = size < 0 ? 0 - (uint64) size : (uint64) size;

My understanding of pg_lltoa() is that it produces an underflow and
relies wrapping around from 0 to PG_UINT64_MAX. In fact the following
SQL, which relies on pg_lltoa() under the hood, panics with `-ftrapv`
enabled (which panics on underflows and overflows):

    SELECT int8out(-9223372036854775808);

So we should actually probably modify pg_lltoa() to use pg_abs_s64()
too.

Thanks,
Joe Koshakow

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

Предыдущее
От: Corey Huinker
Дата:
Сообщение: Re: Statistics Import and Export
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: why is pg_upgrade's regression run so slow?