| 1 |
diff -ur sqlite-src.old/src/util.c sqlite-src-3071700/src/util.c |
| 2 |
--- sqlite-src.old/src/util.c 2013-11-28 09:57:32.167493980 +0100 |
| 3 |
+++ sqlite-src-3071700/src/util.c 2013-11-28 09:59:01.877811972 +0100 |
| 4 |
@@ -511,7 +511,7 @@ |
| 5 |
u = u*10 + c - '0'; |
| 6 |
} |
| 7 |
if( u>LARGEST_INT64 ){ |
| 8 |
- *pNum = SMALLEST_INT64; |
| 9 |
+ *pNum = neg ? SMALLEST_INT64 : LARGEST_INT64; |
| 10 |
}else if( neg ){ |
| 11 |
*pNum = -(i64)u; |
| 12 |
}else{ |
| 13 |
@@ -542,7 +542,6 @@ |
| 14 |
/* zNum is exactly 9223372036854775808. Fits if negative. The |
| 15 |
** special case 2 overflow if positive */ |
| 16 |
assert( u-1==LARGEST_INT64 ); |
| 17 |
- assert( (*pNum)==SMALLEST_INT64 ); |
| 18 |
return neg ? 0 : 2; |
| 19 |
} |
| 20 |
} |
| 21 |
diff -ur sqlite-src.old/src/vdbe.c sqlite-src-3071700/src/vdbe.c |
| 22 |
--- sqlite-src.old/src/vdbe.c 2013-11-28 09:57:32.162493963 +0100 |
| 23 |
+++ sqlite-src-3071700/src/vdbe.c 2013-11-28 10:04:01.533814781 +0100 |
| 24 |
@@ -3465,7 +3465,9 @@ |
| 25 |
** point number. */ |
| 26 |
assert( (pIn3->flags & MEM_Real)!=0 ); |
| 27 |
|
| 28 |
- if( iKey==SMALLEST_INT64 && (pIn3->r<(double)iKey || pIn3->r>0) ){ |
| 29 |
+ if( (iKey==SMALLEST_INT64 && pIn3->r<(double)iKey) |
| 30 |
+ || (iKey==LARGEST_INT64 && pIn3->r>(double)iKey) |
| 31 |
+ ){ |
| 32 |
/* The P3 value is too large in magnitude to be expressed as an |
| 33 |
** integer. */ |
| 34 |
res = 1; |
| 35 |
diff -ur sqlite-src.old/src/vdbemem.c sqlite-src-3071700/src/vdbemem.c |
| 36 |
--- sqlite-src.old/src/vdbemem.c 2013-11-28 09:57:32.162493963 +0100 |
| 37 |
+++ sqlite-src-3071700/src/vdbemem.c 2013-11-28 10:00:14.877065531 +0100 |
| 38 |
@@ -303,15 +303,8 @@ |
| 39 |
|
| 40 |
/* |
| 41 |
** Convert a 64-bit IEEE double into a 64-bit signed integer. |
| 42 |
-** If the double is too large, return 0x8000000000000000. |
| 43 |
-** |
| 44 |
-** Most systems appear to do this simply by assigning |
| 45 |
-** variables and without the extra range tests. But |
| 46 |
-** there are reports that windows throws an expection |
| 47 |
-** if the floating point value is out of range. (See ticket #2880.) |
| 48 |
-** Because we do not completely understand the problem, we will |
| 49 |
-** take the conservative approach and always do range tests |
| 50 |
-** before attempting the conversion. |
| 51 |
+** If the double is out of range of a 64-bit signed integer then |
| 52 |
+** return the closest available 64-bit signed integer. |
| 53 |
*/ |
| 54 |
static i64 doubleToInt64(double r){ |
| 55 |
#ifdef SQLITE_OMIT_FLOATING_POINT |
| 56 |
@@ -328,14 +321,10 @@ |
| 57 |
static const i64 maxInt = LARGEST_INT64; |
| 58 |
static const i64 minInt = SMALLEST_INT64; |
| 59 |
|
| 60 |
- if( r<(double)minInt ){ |
| 61 |
- return minInt; |
| 62 |
- }else if( r>(double)maxInt ){ |
| 63 |
- /* minInt is correct here - not maxInt. It turns out that assigning |
| 64 |
- ** a very large positive number to an integer results in a very large |
| 65 |
- ** negative integer. This makes no sense, but it is what x86 hardware |
| 66 |
- ** does so for compatibility we will do the same in software. */ |
| 67 |
+ if( r<=(double)minInt ){ |
| 68 |
return minInt; |
| 69 |
+ }else if( r>=(double)maxInt ){ |
| 70 |
+ return maxInt; |
| 71 |
}else{ |
| 72 |
return (i64)r; |
| 73 |
} |
| 74 |
@@ -417,17 +406,11 @@ |
| 75 |
** |
| 76 |
** The second and third terms in the following conditional enforces |
| 77 |
** the second condition under the assumption that addition overflow causes |
| 78 |
- ** values to wrap around. On x86 hardware, the third term is always |
| 79 |
- ** true and could be omitted. But we leave it in because other |
| 80 |
- ** architectures might behave differently. |
| 81 |
+ ** values to wrap around. |
| 82 |
*/ |
| 83 |
if( pMem->r==(double)pMem->u.i |
| 84 |
&& pMem->u.i>SMALLEST_INT64 |
| 85 |
-#if defined(__i486__) || defined(__x86_64__) |
| 86 |
- && ALWAYS(pMem->u.i<LARGEST_INT64) |
| 87 |
-#else |
| 88 |
&& pMem->u.i<LARGEST_INT64 |
| 89 |
-#endif |
| 90 |
){ |
| 91 |
pMem->flags |= MEM_Int; |
| 92 |
} |
| 93 |
diff -ur sqlite-src.old/test/autoinc.test sqlite-src-3071700/test/autoinc.test |
| 94 |
--- sqlite-src.old/test/autoinc.test 2013-11-28 09:57:32.145493901 +0100 |
| 95 |
+++ sqlite-src-3071700/test/autoinc.test 2013-11-28 10:00:25.973101898 +0100 |
| 96 |
@@ -216,7 +216,7 @@ |
| 97 |
} {t1 1238} |
| 98 |
do_test autoinc-2.28 { |
| 99 |
execsql { |
| 100 |
- UPDATE sqlite_sequence SET seq='12345678901234567890' |
| 101 |
+ UPDATE sqlite_sequence SET seq='-12345678901234567890' |
| 102 |
WHERE name='t1'; |
| 103 |
INSERT INTO t1 VALUES(NULL,6); |
| 104 |
SELECT * FROM t1; |
| 105 |
diff -ur sqlite-src.old/test/e_expr.test sqlite-src-3071700/test/e_expr.test |
| 106 |
--- sqlite-src.old/test/e_expr.test 2013-11-28 09:57:32.130493848 +0100 |
| 107 |
+++ sqlite-src-3071700/test/e_expr.test 2013-11-28 10:00:32.053121919 +0100 |
| 108 |
@@ -1606,14 +1606,14 @@ |
| 109 |
# an INTEGER then the result of the cast is the largest negative |
| 110 |
# integer: -9223372036854775808. |
| 111 |
# |
| 112 |
-do_expr_test e_expr-31.2.1 { CAST(2e+50 AS INT) } integer -9223372036854775808 |
| 113 |
+do_expr_test e_expr-31.2.1 { CAST(2e+50 AS INT) } integer 9223372036854775807 |
| 114 |
do_expr_test e_expr-31.2.2 { CAST(-2e+50 AS INT) } integer -9223372036854775808 |
| 115 |
do_expr_test e_expr-31.2.3 { |
| 116 |
CAST(-9223372036854775809.0 AS INT) |
| 117 |
} integer -9223372036854775808 |
| 118 |
do_expr_test e_expr-31.2.4 { |
| 119 |
CAST(9223372036854775809.0 AS INT) |
| 120 |
-} integer -9223372036854775808 |
| 121 |
+} integer 9223372036854775807 |
| 122 |
|
| 123 |
|
| 124 |
# EVIDENCE-OF: R-09295-61337 Casting a TEXT or BLOB value into NUMERIC |
Parent Directory
| 
Revision Log
| 
Revision Graph
