On Sun, 28 Jul 2024 at 13:10, Joseph Koshakow <kosh...@gmail.com> wrote: > > On Sat, Jul 27, 2024 at 8:00 PM David Rowley <dgrowle...@gmail.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
#include <stdio.h> #include <limits.h> int main(void) { volatile int v = INT_MIN; unsigned int u = v < 0 ? 0 - (unsigned int) v : (unsigned int) v; printf("%u\n", u); return 0; }
#include <stdio.h> #include <limits.h> int main(void) { volatile int v = INT_MIN; unsigned int u = v < 0 ? (unsigned int) -v : (unsigned int) v; printf("%u\n", u); return 0; }