Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Comment:  Make the doubleToInt64() routine a passthrough when using OMIT_FLOATING_POINT. 

Downloads:  Tarball  ZIP archive  SQL archive 
Timelines:  family  ancestors  descendants  both  trunk 
Files:  files  file ages  folders 
SHA1: 
417167182efaa1da74008952137de3e0 
User & Date:  drh 20100113 15:15:40 
20100113
 
16:25  When SQLITE_OMIT_FLOATING_POINT is defined, make sure the result of a mathematical operation is always tagged as an integer. (checkin: e12da0d3 user: drh tags: trunk)  
15:15  Make the doubleToInt64() routine a passthrough when using OMIT_FLOATING_POINT. (checkin: 41716718 user: drh tags: trunk)  
14:08  Add tests to backup.test to verify that SQLite behaves as expected when the source database is modified midbackup. (checkin: 985d3bec user: dan tags: trunk)  
Changes to src/vdbemem.c.
311
312
313
314
315
316
317
318
319
320
321
322
323
324
...
332
333
334
335
336
337
338
339
340
341
342
343
344
345

** 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.
*/
static i64 doubleToInt64(double r){
/*
** Many compilers we encounter do not define constants for the
** minimum and maximum 64bit integers, or they define them
** inconsistently. And many do not understand the "LL" notation.
** So we define our own static constants here using nothing
** larger than a 32bit integer constant.
*/
................................................................................
** 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;
}
}
/*
** Return some kind of integer value which is the best we can do
** at representing the value that *pMem describes as an integer.
** If pMem is an integer, then the value is exact. If pMem is
** a floatingpoint then the value returned is the integer part.

>
>
>
>
>

311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
...
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350

** 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. */ static i64 doubleToInt64(double r){ #ifdef SQLITE_OMIT_FLOATING_POINT /* When floatingpoint is omitted, double and int64 are the same thing */ return r; #else /* ** Many compilers we encounter do not define constants for the ** minimum and maximum 64bit integers, or they define them ** inconsistently. And many do not understand the "LL" notation. ** So we define our own static constants here using nothing ** larger than a 32bit integer constant. */ ................................................................................ ** 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; } #endif } /* ** Return some kind of integer value which is the best we can do ** at representing the value that *pMem describes as an integer. ** If pMem is an integer, then the value is exact. If pMem is ** a floatingpoint then the value returned is the integer part. 