/ Check-in [41716718]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Make the doubleToInt64() routine a pass-through when using OMIT_FLOATING_POINT.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 417167182efaa1da74008952137de3e00c23494e
User & Date: drh 2010-01-13 15:15:40
Context
2010-01-13
16:25
When SQLITE_OMIT_FLOATING_POINT is defined, make sure the result of a mathematical operation is always tagged as an integer. check-in: e12da0d3 user: drh tags: trunk
15:15
Make the doubleToInt64() routine a pass-through when using OMIT_FLOATING_POINT. check-in: 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 mid-backup. check-in: 985d3bec user: dan tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

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 64-bit 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 32-bit 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 floating-point 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 floating-point 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 64-bit 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 32-bit 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 floating-point then the value returned is the integer part.