spidermonkey cannot handle full 64-bit integers

RESOLVED DUPLICATE of bug 374339

Status

()

Core
JavaScript Engine
--
enhancement
RESOLVED DUPLICATE of bug 374339
10 years ago
8 years ago

People

(Reporter: lazierthanthou, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030506 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030506 Minefield/3.0b5pre

the function fails to return large integers correctly

Reproducible: Always

Steps to Reproduce:
1. open/create a sqlite db file
2. create a table and insert a row as shown in the code below:
---------code begins-------------
var db = Components.classes["@mozilla.org/file/local;1"]
	.createInstance(Components.interfaces.nsILocalFile);
db.initWithPath("c:\\trial.sqlite");
//creates/opens the file in variable 'db'
var conn = Components.classes["@mozilla.org/storage/service;1"]
      .getService(Components.interfaces.mozIStorageService)
      .openDatabase(db);

//create a table
var st = conn.createStatement("create table `trial` " +
             "(`veryBigInt` integer primary key)");
st.execute();

//insert a row with a big number
st = conn.createStatement("insert into `trial` " +
             "(`veryBigInt`) values (1234567890123456789)");
st.execute();

//fetch the row
var stmt = conn.createStatement("select * from trial");
stmt.executeStep();

//display the value in column 1 which is an integer
var cell = stmt.getInt64(0);
alert(cell);
---------code ends-------------

3. execute the select statement above from the commandline using sqlite3.exe (WinXP)
Actual Results:  
step 2: the output of alert is = 1234567890123456800
step 3: the value shown is = 1234567890123456789

Expected Results:  
the result in step2 should be as in step3
(Reporter)

Updated

10 years ago
Version: unspecified → Trunk
I bet it matches if you use bind parameter.  JS engine limitation?
(Reporter)

Comment 2

10 years ago
(In reply to comment #1)
> I bet it matches if you use bind parameter.  JS engine limitation?
> 

How can I bind parameter in "select * from trial"?
Change your insert to this:
st = conn.createStatement("insert into `trial` " +
             "(`veryBigInt`) values (?1)");
st.bindInt64Parameter(0, 1234567890123456789);
st.execute();
(Reporter)

Comment 4

10 years ago
(In reply to comment #3)
> Change your insert to this:
> st = conn.createStatement("insert into `trial` " +
>              "(`veryBigInt`) values (?1)");
> st.bindInt64Parameter(0, 1234567890123456789);
> st.execute();
> 

i will try this but I think it is not necessary. Because, when I use the command line sqlite3.exe to query the table, I find that the value has been correctly entered into the table.

Just to be sure, let us (at this stage) close firefox too. Query the db again using sqlite3.exe and the result is correct. Means, there is no problem at the insert stage. Now, started firefox again and executed the select statement only. The result, at this stage too, is incorrect.
You aren't understanding what I'm saying.  I'm saying that the JS engine cannot represent the number you have in the database.  I'm *not* saying that it's getting inserted into the database incorrectly.  However, inserting it with the bind parameter will indicate if it is the JS engine that's at fault here because the results should be the same in that case (the inserted value will not be what you inserted).
(Reporter)

Comment 6

10 years ago
(In reply to comment #5)
> You aren't understanding what I'm saying.  I'm saying that the JS engine cannot
> represent the number you have in the database.  I'm *not* saying that it's
> getting inserted into the database incorrectly.  However, inserting it with the
> bind parameter will indicate if it is the JS engine that's at fault here
> because the results should be the same in that case (the inserted value will
> not be what you inserted).
> 

yes, i did not understand. On using the insert suggested by you, the results are as follows:
step 2 (alert output):      1234567890123456800
step 3 (using sqlite3.exe): 1234567890123456768

(for the meaning of step 2 and 3, see the description of the bug)
(Reporter)

Comment 7

10 years ago
Shouldn't the severity of this bug be major?

If from the above discussion, we can infer that JS engine is at fault (as suggested in comment #5) then who to address it to to have it fixed?
There is no way to represent the full range of a 64-bit integer in our engine (nor, to my knowledge, in any others) -- I would recommend having getInt64 return the lo and hi distinctly (can use destructuring for better syntax) and having setInt64 accept lo and hi separately as well.

Call it fault if you want, and feel free to file an ENH on Spidermonkey to support 64-bit integer values, but I don't think it'll improve at any time in the near future.  (JS2 will give us the needed bits to implement a 64-int workalike, I think.)

Comment 9

10 years ago
fwiw this also results in the necko apis not working properly for 64bit sizes, xpconnect is limited by spidermonkey. in theory one could change xpconnect to provide a wrapper object for 64bit numbers instead, however performing any mathematical operations on such an object would be painful.

for people who want to see xpconnect eat your number directly, this works:
js> PRInt64=Components.Constructor("@mozilla.org/supports-PRInt64;1","nsISupportsPRInt64");print64=new PRInt64;print64.data=1234567890123456789
1234567890123456800

shaver: assuming they're using xpidl, how does one write a destructuring interface?
[scriptable] interface sqlIFoo{void bar(/* we promise length=2 */ out long length, [retval, array, size_is(length)] out long result);}
(hi,lo)=x.sqlIFoo.bar({});

Updated

9 years ago
Assignee: nobody → general
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: Storage → JavaScript Engine
Ever confirmed: true
Product: Toolkit → Core
QA Contact: storage → general
Summary: problem in getInt64() function → spidermonkey cannot handle full 64-bit integers

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 374339
You need to log in before you can comment on or make changes to this bug.