Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Add a comment to the doubleToInt64() routine that explains why returning minInt is in fact correct when it seems like maxInt should be returned. (CVS 6405) |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: | 7f3be3608542bbc6ac7916e5c3a5436e |
| User & Date: | drh 2009-03-29 15:12:10 |
Context
|
2009-03-30
| ||
| 07:39 | Another change related to (6401) and (6402): When an attempt to unlock a file fails in os_unix.c, close all files held open waiting for the unlock event anyway. This prevents a file-descriptor leak when testing IO errors. (CVS 6406) check-in: 50fbcdea user: danielk1977 tags: trunk | |
|
2009-03-29
| ||
| 15:12 | Add a comment to the doubleToInt64() routine that explains why returning minInt is in fact correct when it seems like maxInt should be returned. (CVS 6405) check-in: 7f3be360 user: drh tags: trunk | |
| 00:15 | Turn off the debugging macros in where.c - left on by mistake in the previous check-in. (CVS 6404) check-in: b601a575 user: drh tags: trunk | |
Changes
Changes to src/vdbemem.c.
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
...
317
318
319
320
321
322
323
324
325
326
327
328
329
330
|
************************************************************************* ** ** This file contains code use to manipulate "Mem" structure. A "Mem" ** stores a single value in the VDBE. Mem is an opaque structure visible ** only within the VDBE. Interface routines refer to a Mem using the ** name sqlite_value ** ** $Id: vdbemem.c,v 1.138 2009/03/23 21:37:04 drh Exp $ */ #include "sqliteInt.h" #include "vdbeInt.h" /* ** Call sqlite3VdbeMemExpandBlob() on the supplied value (type Mem*) ** P if required. ................................................................................ */ static const i64 maxInt = LARGEST_INT64; static const i64 minInt = SMALLEST_INT64; if( r<(double)minInt ){ return minInt; }else if( r>(double)maxInt ){ return minInt; }else{ return (i64)r; } } /* |
|
>
>
>
>
|
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
...
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
|
************************************************************************* ** ** This file contains code use to manipulate "Mem" structure. A "Mem" ** stores a single value in the VDBE. Mem is an opaque structure visible ** only within the VDBE. Interface routines refer to a Mem using the ** name sqlite_value ** ** $Id: vdbemem.c,v 1.139 2009/03/29 15:12:10 drh Exp $ */ #include "sqliteInt.h" #include "vdbeInt.h" /* ** Call sqlite3VdbeMemExpandBlob() on the supplied value (type Mem*) ** P if required. ................................................................................ */ 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. */ return minInt; }else{ return (i64)r; } } /* |