Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow
Date
Msg-id CAH2-WzmxAi3R+JEbdMr17h=Ecf=aVywYi138Qnym=EyG2nwOpQ@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Wed, Jul 12, 2017 at 9:20 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> Uh ... what assumption?  That's certainly true on any twos-complement
>> machine.  Besides, if you're worried about hypothetical portability
>> issues, ...
>
>
> Right, it's a hypothetical portability issue. The assumption we're making is
> that UINT_MAX >= INT_MAX * 2 + 1. I'm not aware of any system where it's not
> true, but I don't know what the C standards say about that.

Intuitively, it seems very likely to be true, since two's complement
arithmetic is already assumed by Postgres, and addition and
multiplication work the same way at the instruction level for unsigned
and signed (two's complement) integers. In order for this to break,
int and unsigned int would have to have different widths.

> Well, you could do Min(INT_MAX, (UINT_MAX - 1 / 2). Or just add a
> StaticAssertion for it. Or just note in a comment that we're making that
> assumption.

I like the idea of a StaticAssertion().

-- 
Peter Geoghegan


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow