Improve handling of INT_MIN / -1 and related cases.

Some platforms throw an exception for this division, rather than returning
a necessarily-overflowed result.  Since we were testing for overflow after
the fact, an exception isn't nice.  We can avoid the problem by treating
division by -1 as negation.

Add some regression tests so that we'll find out if any compilers try to
optimize away the overflow check conditions.

Back-patch of commit 1f7cb5c30983752ff8de833de30afcaee63536d0.

Per discussion with Xi Wang, though this is different from the patch he
submitted.

1 files changed, 56 insertions, 52 deletions

diff --git a/src/backend/utils/adt/int.c b/src/backend/utils/adt/int.c
index 5fcdb19389f..07493e3c3f8 100644
--- a/src/backend/utils/adt/int.c
+++ b/src/backend/utils/adt/int.c
@@ -681,18 +681,6 @@ int4mul(PG_FUNCTION_ARGS)
 	int32		arg2 = PG_GETARG_INT32(1);
 	int32		result;
 
-#ifdef WIN32
-
-	/*
-	 * Win32 doesn't throw a catchable exception for SELECT -2147483648 *
-	 * (-1);  -- INT_MIN
-	 */
-	if (arg2 == -1 && arg1 == INT_MIN)
-		ereport(ERROR,
-				(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
-				 errmsg("integer out of range")));
-#endif
-
 	result = arg1 * arg2;
 
 	/*
@@ -709,7 +697,8 @@ int4mul(PG_FUNCTION_ARGS)
 	if (!(arg1 >= (int32) SHRT_MIN && arg1 <= (int32) SHRT_MAX &&
 		  arg2 >= (int32) SHRT_MIN && arg2 <= (int32) SHRT_MAX) &&
 		arg2 != 0 &&
-		(result / arg2 != arg1 || (arg2 == -1 && arg1 < 0 && result < 0)))
+		((arg2 == -1 && arg1 < 0 && result < 0) ||
+		 result / arg2 != arg1))
 		ereport(ERROR,
 				(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
 				 errmsg("integer out of range")));
@@ -732,30 +721,27 @@ int4div(PG_FUNCTION_ARGS)
 		PG_RETURN_NULL();
 	}
 
-#ifdef WIN32
-
 	/*
-	 * Win32 doesn't throw a catchable exception for SELECT -2147483648 /
-	 * (-1); -- INT_MIN
+	 * INT_MIN / -1 is problematic, since the result can't be represented on a
+	 * two's-complement machine.  Some machines produce INT_MIN, some produce
+	 * zero, some throw an exception.  We can dodge the problem by recognizing
+	 * that division by -1 is the same as negation.
 	 */
-	if (arg2 == -1 && arg1 == INT_MIN)
-		ereport(ERROR,
-				(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
-				 errmsg("integer out of range")));
-#endif
+	if (arg2 == -1)
+	{
+		result = -arg1;
+		/* overflow check (needed for INT_MIN) */
+		if (arg1 != 0 && SAMESIGN(result, arg1))
+			ereport(ERROR,
+					(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
+					 errmsg("integer out of range")));
+		PG_RETURN_INT32(result);
+	}
+
+	/* No overflow is possible */
 
 	result = arg1 / arg2;
 
-	/*
-	 * Overflow check.	The only possible overflow case is for arg1 = INT_MIN,
-	 * arg2 = -1, where the correct result is -INT_MIN, which can't be
-	 * represented on a two's-complement machine.  Most machines produce
-	 * INT_MIN but it seems some produce zero.
-	 */
-	if (arg2 == -1 && arg1 < 0 && result <= 0)
-		ereport(ERROR,
-				(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
-				 errmsg("integer out of range")));
 	PG_RETURN_INT32(result);
 }
 
@@ -877,18 +863,27 @@ int2div(PG_FUNCTION_ARGS)
 		PG_RETURN_NULL();
 	}
 
-	result = arg1 / arg2;
-
 	/*
-	 * Overflow check.	The only possible overflow case is for arg1 =
-	 * SHRT_MIN, arg2 = -1, where the correct result is -SHRT_MIN, which can't
-	 * be represented on a two's-complement machine.  Most machines produce
-	 * SHRT_MIN but it seems some produce zero.
+	 * SHRT_MIN / -1 is problematic, since the result can't be represented on
+	 * a two's-complement machine.  Some machines produce SHRT_MIN, some
+	 * produce zero, some throw an exception.  We can dodge the problem by
+	 * recognizing that division by -1 is the same as negation.
 	 */
-	if (arg2 == -1 && arg1 < 0 && result <= 0)
-		ereport(ERROR,
-				(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
-				 errmsg("smallint out of range")));
+	if (arg2 == -1)
+	{
+		result = -arg1;
+		/* overflow check (needed for SHRT_MIN) */
+		if (arg1 != 0 && SAMESIGN(result, arg1))
+			ereport(ERROR,
+					(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
+					 errmsg("smallint out of range")));
+		PG_RETURN_INT16(result);
+	}
+
+	/* No overflow is possible */
+
+	result = arg1 / arg2;
+
 	PG_RETURN_INT16(result);
 }
 
@@ -1065,18 +1060,27 @@ int42div(PG_FUNCTION_ARGS)
 		PG_RETURN_NULL();
 	}
 
-	result = arg1 / arg2;
-
 	/*
-	 * Overflow check.	The only possible overflow case is for arg1 = INT_MIN,
-	 * arg2 = -1, where the correct result is -INT_MIN, which can't be
-	 * represented on a two's-complement machine.  Most machines produce
-	 * INT_MIN but it seems some produce zero.
+	 * INT_MIN / -1 is problematic, since the result can't be represented on a
+	 * two's-complement machine.  Some machines produce INT_MIN, some produce
+	 * zero, some throw an exception.  We can dodge the problem by recognizing
+	 * that division by -1 is the same as negation.
 	 */
-	if (arg2 == -1 && arg1 < 0 && result <= 0)
-		ereport(ERROR,
-				(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
-				 errmsg("integer out of range")));
+	if (arg2 == -1)
+	{
+		result = -arg1;
+		/* overflow check (needed for INT_MIN) */
+		if (arg1 != 0 && SAMESIGN(result, arg1))
+			ereport(ERROR,
+					(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
+					 errmsg("integer out of range")));
+		PG_RETURN_INT32(result);
+	}
+
+	/* No overflow is possible */
+
+	result = arg1 / arg2;
+
 	PG_RETURN_INT32(result);
 }