Re: BUG #5592: list of integer undefined behaviors

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Mon, Aug 2, 2010 at 7:16 PM, John Regehr <regehr(at)cs(dot)utah(dot)edu> wrote:
>> <nabstime.c, (1193:21)> : Op: -, Reason : Signed Subtraction Overflow,
>> BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648
>>
>> <nabstime.c, (1194:21)> : Op: -, Reason : Signed Subtraction Overflow,
>> BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648

> These seem to imply that tinterval can contain a start point greater
> than its end point.

On closer investigation, the problem is just that you can't fit the
difference INT_MAX minus INT_MIN into an int :-(.

The particular values cited appear to be NOEND_ABSTIME and
NOSTART_ABSTIME, ie "infinity" and "-infinity" in the abstime datatype,
so this is coming from tinterval comparisons involving this value
in the regression tests:

INSERT INTO TINTERVAL_TBL (f1)
VALUES ('["-infinity" "infinity"]');

Although this is the worst case, you could easily get overflows from
intervals with ordinary endpoints that are sufficiently far apart.

Since this is a nearly-dead legacy datatype, I can't get excited about
spending a lot of time on it. What I suggest we do is do the difference
calculation in int64 arithmetic instead of int32.

Another complaint that could be leveled against this code is that
infinity and minus infinity behave way too much like ordinary mortal
timestamps. It would be very easy to select finite timestamps
a, b, c such that this code thinks [a b] is a longer interval than
[c infinity], which is surprising to say the least. However, I can't
get excited about fixing that for abstime/tinterval. It might be
something to consider if anyone ever reimplements this type in a way
that isn't going to fall over in 2038.

regards, tom lane