Mojo: Correctly handle large unsigned integer literals.

mojo/apps/js/bindings/sample_service_unittests.js

Index: mojo/apps/js/bindings/sample_service_unittests.js
diff --git a/mojo/apps/js/bindings/sample_service_unittests.js b/mojo/apps/js/bindings/sample_service_unittests.js
index 46a53c42f051171ea0802e424b907ba3f236df26..a2fa8eb81dc984271eb565ca3b160e70a4834161 100644
--- a/mojo/apps/js/bindings/sample_service_unittests.js
+++ b/mojo/apps/js/bindings/sample_service_unittests.js
@@ -104,12 +104,11 @@ define([
     expect(defaults.a2).toBe(1234);
     expect(defaults.a3).toBe(34567);
     expect(defaults.a4).toBe(123456);
-    // TODO(vtl): crbug.com/375522
-    // expect(defaults.a5).toBe(3456789012);
+    expect(defaults.a5).toBe(3456789012);
     expect(defaults.a6).toBe(111111111111);
-    // TODO(vtl): crbug.com/375522 (Also, can we get exact values for large
-    // int64/uint64's in JS?)
-    // expect(defaults.a7).toBe(9999999999999999999);
+    // JS doesn't have a 64 bit integer type so this is just checking that the

[viettrungluu, 2014/07/15 16:08:26]

Partly/vaguely implied by my parenthetical comment is the question of whether we
should have additional methods to get an exact representation of 64-bit types in
JS (e.g., as a high-/low-order pair of numbers or as an ArrayBuffer). Probably
we should, in which case I guess I should file a bug for that.

(Also, I suppose if we were keen, we'd test that we get exact integers at least
out to +/- 2^52 or whatever it is.)

+    // expected and actual values have the same closest double value.
+    expect(defaults.a7).toBe(9999999999999999999);
     expect(defaults.a8).toBe(0x12345);
     expect(defaults.a9).toBe(-0x12345);
     expect(defaults.a10).toBe(1234);