SQLite User Forum

Bug Report: Constant Doubling in REAL with Specific Prefixes
Login

Bug Report: Constant Doubling in REAL with Specific Prefixes

(1.1) By QueryHouse on 2024-12-07 11:26:19 edited from 1.0 [source]

Hi,

We have identified an issue in SQLite version 3.47.0.

Issue: Constant Doubling in REAL with Specific Prefixes

According to the official documentation, integers greater than 9223372036854775807 are treated as floating point integers (REAL, as an 8-byte IEEE floating point number). This suggests SQLite can handle numbers within the 8B IEEE float range. Here’s the relevant part of the documentation:

However, we've observed that some integers that can be represented by REAL are incorrectly doubled.

Steps to Reproduce:

The issue can be reproduced with the following minimized query:

SELECT 18446744073709551488;

Expected Result:

1.84467440737096e+19
The constant 18446744073709551488 should be treated as a floating point number, possibly with some precision loss.

Actual result (SQLite, version 3.48.0, as of 2024-10-02 13:26:17):

3.68934881474191e+19
SQLite returns a doubled float representation, despite the number being representable with an 8B IEEE float. This is quite far from a precision loss.

Bug Pattern:

Upon further analysis, we found that integers satisfying the following conditions are doubled:

  1. Exceeding 9223372036854775807, thus treated as REAL
  2. Prefixed with 18446744073709550592 ~ 18446744073709551609

Here are additional test cases supporting this:

-- Erroneous range: 18446744073709550592 ~ 18446744073709551609
sqlite> SELECT 18446744073709550591;  -- 0xfffffffffffffbff
1.84467440737095e+19
sqlite> SELECT 18446744073709550592;  -- 0xfffffffffffffc00
3.68934881474191e+19
...
sqlite> SELECT 18446744073709551488;  -- 0xffffffffffffff80
3.68934881474191e+19
...
sqlite> SELECT 18446744073709551609; -- 0xfffffffffffffff9
3.68934881474191e+19
sqlite> SELECT 18446744073709551610; -- 0xfffffffffffffffa
1.84467440737096e+19

-- Another erroneous range: 184467440737095505920 ~ 184467440737095516099
sqlite> SELECT 184467440737095505919; -- 0x9ffffffffffffd7ff
1.84467440737096e+20
sqlite> SELECT 184467440737095505920; -- 0x9ffffffffffffd800
3.68934881474191e+20
...
sqlite> SELECT 184467440737095505990; -- 0x9ffffffffffffd846
3.68934881474191e+20
...
sqlite> SELECT 184467440737095516099; -- 0x9ffffffffffffffc3
3.68934881474191e+20
sqlite> SELECT 184467440737095516100; -- 0x9ffffffffffffffc4
1.84467440737096e+20

-- Another erroneous range: 184467440737095505920000000 ~ 184467440737095516099999999
sqlite> SELECT 184467440737095505920000000;
3.68934881474191e+26
sqlite> SELECT 184467440737095516099999999;
3.68934881474191e+26

Bug-Introducing Commit:

We identified the bug-introducing commit (with default options):

The issue appeared only after this commit, which removed the LONG DOUBLE support.

Thank you for your time and attention to this matter. We look forward to your response.

Best regards.

(2) By Harald Hanche-Olsen (hanche) on 2024-12-07 12:13:57 in reply to 1.1 [link] [source]

Is this architecture dependent?

I cannot reproduce this on my M1 Macbook pro.

The output of .version is

SQLite 3.48.0 2024-10-27 07:06:03 2a881a2e1b7355c7733c3a41a82290ba6f3983232a9ec378d9a1b62ee4109f54
zlib version 1.2.12
clang-16.0.0 (64-bit)

i.e., later than the the reported bug introducing checkin.

(3) By Richard Hipp (drh) on 2024-12-07 12:43:23 in reply to 2 [link] [source]

Problem seems to be CPU-specific. I can see it on x86 on Linux, Mac, and Windows. But on ARM7 (Linux and MacOS) it does not happen. Still testing on PPC (that machine is so slow that it takes a while to build a new "sqlite3"...)

(4) By Richard Hipp (drh) on 2024-12-07 15:08:51 in reply to 1.1 [link] [source]

Thank you for the report.

Can you please confirm that the issue is resolved by check-in https://sqlite.org/src/info/81342fa6dd03fffb and is also fixed in branch-3.47 at check-in https://sqlite.org/src/info/17537a98cb31ab41?

(5) By QueryHouse on 2024-12-08 06:45:51 in reply to 4 [link] [source]

Thank you for the update!

We have confirmed that the issue is resolved based on both of the check-ins you mentioned.