From f1f7a85d8c3ed914f4d0df93e40f0144931af315 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 17 Mar 2018 15:38:15 -0400 Subject: [PATCH] Fix overflow handling in plpgsql's integer FOR loops. The test to exit the loop if the integer control value would overflow an int32 turns out not to work on some ICC versions, as it's dependent on the assumption that the compiler will execute the code as written rather than "optimize" it. ICC lacks any equivalent of gcc's -fwrapv switch, so it was optimizing on the assumption of no integer overflow, and that breaks this. Rewrite into a form that in fact does not do any overflowing computations. Per Tomas Vondra and buildfarm member fulmar. It's been like this for a long time, although it was not till we added a regression test case covering the behavior (in commit dd2243f2a) that the problem became apparent. Back-patch to all supported versions. Discussion: https://postgr.es/m/50562fdc-0876-9843-c883-15b8566c7511@2ndquadrant.com --- src/pl/plpgsql/src/pl_exec.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c index 9601345c84a..1ff33a44b21 100644 --- a/src/pl/plpgsql/src/pl_exec.c +++ b/src/pl/plpgsql/src/pl_exec.c @@ -38,6 +38,9 @@ #include "utils/snapmgr.h" #include "utils/typcache.h" +#define PG_INT32_MIN (-0x7FFFFFFF-1) +#define PG_INT32_MAX (0x7FFFFFFF) + static const char *const raise_skip_msg = "RAISE"; @@ -1997,13 +2000,13 @@ exec_stmt_fori(PLpgSQL_execstate *estate, PLpgSQL_stmt_fori *stmt) */ if (stmt->reverse) { - if ((int32) (loop_value - step_value) > loop_value) + if (loop_value < (PG_INT32_MIN + step_value)) break; loop_value -= step_value; } else { - if ((int32) (loop_value + step_value) < loop_value) + if (loop_value > (PG_INT32_MAX - step_value)) break; loop_value += step_value; }