Bug 848464 - gobject javascript bindings cannot use 64 bit integers
gobject javascript bindings cannot use 64 bit integers
Status: NEW
Product: Virtualization Tools
Classification: Community
Component: libguestfs (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard W.M. Jones
Depends On:
  Show dependency treegraph
Reported: 2012-08-15 12:38 EDT by Richard W.M. Jones
Modified: 2015-03-12 11:44 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2012-08-15 12:38:36 EDT
Description of problem:

64 bit integers cannot be used reliably via the Javascript
GObject bindings.  This applies to gjs, I didn't test anything
else.  It applies to integer literals, but my belief is this
bug would affect any 64 bit number, not just source code literals
but ones eg. read in from external sources or passed through
to the API from return values from other functions.

Version-Release number of selected component (if applicable):

libguestfs 1.19.30

How reproducible:


Steps to Reproduce:
1. ./run gjs gobject/bindtests.js

Actual results:

Fails on the following line:
o = new Guestfs.InternalTest({obool: true, oint: 1, oint64: 9223372036854775807});
with the error:

    JS ERROR: !!!   Exception was: Error: can't convert 9223372036854776000 to an integer
    JS ERROR: !!!     message = '"can't convert 9223372036854776000 to an integer"'
    JS ERROR: !!!     fileName = '"gobject/bindtests.js"'
    JS ERROR: !!!     lineNumber = '27'
    JS ERROR: !!!     stack = '"@gobject/bindtests.js:27
Error: can't convert 9223372036854776000 to an integer

Additional info:

There seem to be two interacting problems.

(1) Javascript cannot represent 64 bit integers accurately.  We should
be using another type, eg. string.

(2) GObject Introspection converts the number to a 32 bit integer and
fails on overflow, so any time we try to use a number which is larger
than can be held in a 32 bit integer, this is going to fail.
Comment 1 Richard W.M. Jones 2012-11-30 09:36:44 EST
I had a look into this, and here are my findings:

(1) GObject is a world of pain.  It's a wonder it works at all.

(2) gjs is a thin wrapper around SpiderMonkey, which is the same
Javascript engine used by Firefox (ie. written by Mozilla).

(3) SpiderMonkey has a well-defined embedding API, mainly
designed so you can use it from other applications.  See:

(4) gjs supports "native modules".  These are .so objects which
are dlopened and load into gjs, they are present on the search
path etc.  All the examples use GObject, but I'm not sure if that's
required -- apart from GObject stupid, most of them just make
direct JSAPI calls.

$ ls -l /usr/lib64/gjs-1.0/
total 240
-rwxr-xr-x. 1 root root 90280 Sep 25 16:52 cairoNative.so
-rwxr-xr-x. 1 root root 11288 Sep 25 16:52 console.so
-rwxr-xr-x. 1 root root 71096 Sep 25 16:52 dbusNative.so
-rwxr-xr-x. 1 root root  6960 Sep 25 16:52 debugger.so
-rwxr-xr-x. 1 root root  7000 Sep 25 16:52 formatNative.so
-rwxr-xr-x. 1 root root 11200 Sep 25 16:52 gettextNative.so
-rwxr-xr-x. 1 root root  6984 Sep 25 16:52 langNative.so
-rwxr-xr-x. 1 root root 15600 Sep 25 16:52 mainloop.so
-rwxr-xr-x. 1 root root 11184 Sep 25 16:52 system.so

So could we not write the Javascript bindings either directly
using the JSAPI, or that plus a thin gjs "native module"
wrapper?  That would eliminate use of GObject Introspection,
and possibly even GObject entirely.

Note You need to log in before you can comment on or make changes to this bug.