Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Fix overflow handling in plpgsql's integer FOR loops.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 17 Mar 2018 19:38:15 +0000 (15:38 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 17 Mar 2018 19:38:15 +0000 (15:38 -0400)
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

index 9601345c84a32915df2179c715ad16c068450506..1ff33a44b211efa44ad89472e3f6f17b8f14b73f 100644 (file)
@@ -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;
        }