On 2012-11-19 11:04:31 -0500, Tom Lane wrote:
> Xi Wang writes:
> > Since INTn_MIN and INTn_MAX are standard macros from the C library,
> > can we assume that every C compiler should provide them in stdint.h?
>
> Not every C compiler provides stdint.h, unfortunately --- otherwise
> I'd not be so r
Xi Wang writes:
> The reality is that C compilers are not friendly to postcondition
> checking; they consider signed integer overflow as undefined behavior,
> so they do whatever they want to do. Even workaround options like
> -fwrapv are often broken, not to mention that they may not even have
>
On 11/19/12 11:04 AM, Tom Lane wrote:
> I thought about this some more and realized that we can handle it
> by realizing that division by -1 is the same as negation, and so
> we can copy the method used in int4um. So the code would look like
>
> if (arg2 == -1)
> {
> res
Xi Wang writes:
> On 11/18/12 6:47 PM, Tom Lane wrote:
>> I was against this style of coding before, and I still am.
>> For one thing, it's just about certain to introduce conflicts
>> against system headers.
> I totally agree.
> I would be happy to rewrite the integer overflow checks without
>
On 11/18/12 6:47 PM, Tom Lane wrote:
> Xi Wang writes:
>> [ patch adding a bunch of explicit INT_MIN/MAX constants ]
>
> I was against this style of coding before, and I still am.
> For one thing, it's just about certain to introduce conflicts
> against system headers.
I totally agree.
I would
Xi Wang writes:
> [ patch adding a bunch of explicit INT_MIN/MAX constants ]
I was against this style of coding before, and I still am.
For one thing, it's just about certain to introduce conflicts
against system headers.
regards, tom lane
--
Sent via pgsql-hackers mai
The INT_MIN / -1 crash problem was partially addressed in 2006 and
commit 9fc6f4e1ae107f44807c4906105e1f7eb052ecb1.
http://archives.postgresql.org/pgsql-patches/2006-06/msg00102.php
However, the fix is incomplete and incorrect for some cases.
64-bit crash
Below is an example that c