Re: Fix overflow in pg_size_pretty

On Sun, 28 Jul 2024 at 13:10, Joseph Koshakow <koshy44(at)gmail(dot)com> wrote:
>
> On Sat, Jul 27, 2024 at 8:00 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > 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);

I didn't test to see where that's coming from, but I did test the two
attached .c files. int.c uses the 0 - (unsigned int) var method and
int2.c uses (unsigned int) (-var). Using clang and -ftrapv, I get:

$ clang int.c -o int -O2 -ftrapv
$ ./int
2147483648
$ clang int2.c -o int2 -O2 -ftrapv
$ ./int2
Illegal instruction

Similar with gcc:
$ gcc int.c -o int -O2 -ftrapv
$ ./int
2147483648
$ gcc int2.c -o int2 -O2 -ftrapv
$ ./int2
Aborted

I suspect your trap must be coming from somewhere else. It looks to me
like the "uint64 usize = size < 0 ? 0 - (uint64) size : (uint64)
size;" will be fine.

David