diff -ur sqlite-src.old/src/util.c sqlite-src-3071700/src/util.c

--- sqlite-src.old/src/util.c	2013-11-28 09:57:32.167493980 +0100

+++ sqlite-src-3071700/src/util.c	2013-11-28 09:59:01.877811972 +0100

@@ -511,7 +511,7 @@

     u = u*10 + c - '0';

   }

   if( u>LARGEST_INT64 ){

-    *pNum = SMALLEST_INT64;

+    *pNum = neg ? SMALLEST_INT64 : LARGEST_INT64;

   }else if( neg ){

     *pNum = -(i64)u;

   }else{

@@ -542,7 +542,6 @@

       /* zNum is exactly 9223372036854775808.  Fits if negative.  The

       ** special case 2 overflow if positive */

       assert( u-1==LARGEST_INT64 );

-      assert( (*pNum)==SMALLEST_INT64 );

       return neg ? 0 : 2;

     }

   }

diff -ur sqlite-src.old/src/vdbe.c sqlite-src-3071700/src/vdbe.c

--- sqlite-src.old/src/vdbe.c	2013-11-28 09:57:32.162493963 +0100

+++ sqlite-src-3071700/src/vdbe.c	2013-11-28 10:04:01.533814781 +0100

@@ -3465,7 +3465,9 @@

         ** point number. */

         assert( (pIn3->flags & MEM_Real)!=0 );

-        if( iKey==SMALLEST_INT64 && (pIn3->r<(double)iKey || pIn3->r>0) ){

+        if( (iKey==SMALLEST_INT64 && pIn3->r<(double)iKey)

+         || (iKey==LARGEST_INT64 && pIn3->r>(double)iKey)

+        ){

           /* The P3 value is too large in magnitude to be expressed as an

           ** integer. */

           res = 1;

diff -ur sqlite-src.old/src/vdbemem.c sqlite-src-3071700/src/vdbemem.c

--- sqlite-src.old/src/vdbemem.c	2013-11-28 09:57:32.162493963 +0100

+++ sqlite-src-3071700/src/vdbemem.c	2013-11-28 10:00:14.877065531 +0100

@@ -303,15 +303,8 @@

 /*

 ** Convert a 64-bit IEEE double into a 64-bit signed integer.

-** If the double is too large, return 0x8000000000000000.

-**

-** Most systems appear to do this simply by assigning

-** variables and without the extra range tests.  But

-** there are reports that windows throws an expection

-** if the floating point value is out of range. (See ticket #2880.)

-** Because we do not completely understand the problem, we will

-** take the conservative approach and always do range tests

-** before attempting the conversion.

+** If the double is out of range of a 64-bit signed integer then

+** return the closest available 64-bit signed integer.

 */

 static i64 doubleToInt64(double r){

 #ifdef SQLITE_OMIT_FLOATING_POINT

@@ -328,14 +321,10 @@

   static const i64 maxInt = LARGEST_INT64;

   static const i64 minInt = SMALLEST_INT64;

-  if( r<(double)minInt ){

-    return minInt;

-  }else if( r>(double)maxInt ){

-    /* minInt is correct here - not maxInt.  It turns out that assigning

-    ** a very large positive number to an integer results in a very large

-    ** negative integer.  This makes no sense, but it is what x86 hardware

-    ** does so for compatibility we will do the same in software. */

+  if( r<=(double)minInt ){

     return minInt;

+  }else if( r>=(double)maxInt ){

+    return maxInt;

   }else{

     return (i64)r;

   }

@@ -417,17 +406,11 @@

   **

   ** The second and third terms in the following conditional enforces

   ** the second condition under the assumption that addition overflow causes

-  ** values to wrap around.  On x86 hardware, the third term is always

-  ** true and could be omitted.  But we leave it in because other

-  ** architectures might behave differently.

+  ** values to wrap around.

   */

   if( pMem->r==(double)pMem->u.i

    && pMem->u.i>SMALLEST_INT64

-#if defined(__i486__) || defined(__x86_64__)

-   && ALWAYS(pMem->u.i

-#else

    && pMem->u.i

-#endif

   ){

     pMem->flags |= MEM_Int;

   }

diff -ur sqlite-src.old/test/autoinc.test sqlite-src-3071700/test/autoinc.test

--- sqlite-src.old/test/autoinc.test	2013-11-28 09:57:32.145493901 +0100

+++ sqlite-src-3071700/test/autoinc.test	2013-11-28 10:00:25.973101898 +0100

@@ -216,7 +216,7 @@

 } {t1 1238}

 do_test autoinc-2.28 {

   execsql {

-    UPDATE sqlite_sequence SET seq='12345678901234567890'

+    UPDATE sqlite_sequence SET seq='-12345678901234567890'

       WHERE name='t1';

     INSERT INTO t1 VALUES(NULL,6);

     SELECT * FROM t1;

diff -ur sqlite-src.old/test/e_expr.test sqlite-src-3071700/test/e_expr.test

--- sqlite-src.old/test/e_expr.test	2013-11-28 09:57:32.130493848 +0100

+++ sqlite-src-3071700/test/e_expr.test	2013-11-28 10:00:32.053121919 +0100

@@ -1606,14 +1606,14 @@

 # an INTEGER then the result of the cast is the largest negative

 # integer: -9223372036854775808.

 #

-do_expr_test e_expr-31.2.1 { CAST(2e+50 AS INT) } integer -9223372036854775808

+do_expr_test e_expr-31.2.1 { CAST(2e+50 AS INT) } integer 9223372036854775807

 do_expr_test e_expr-31.2.2 { CAST(-2e+50 AS INT) } integer -9223372036854775808

 do_expr_test e_expr-31.2.3 { 

   CAST(-9223372036854775809.0 AS INT)

 } integer -9223372036854775808

 do_expr_test e_expr-31.2.4 { 

   CAST(9223372036854775809.0 AS INT)

-} integer -9223372036854775808

+} integer 9223372036854775807

 # EVIDENCE-OF: R-09295-61337 Casting a TEXT or BLOB value into NUMERIC