Make number serialization compatible with V8 (and new IETF spec draft)

[cyberphone]

In order to create signed JavaScript objects, you need to normalize data.

The JCS specification https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#ECMAScript_Compatibility_Mode accomplish this "automatically" by relying on ES6 for property order (which Chakra implements), but also depends on the extended number formatting algorithm used in the Google V8 engine which after testing with 100 million of random and selected values appears to be used by Chrome, Firefox, and Safari as well as "node.js".

Browser test program:
http://webpki.org/ietf/es6numberbrowsertest.html

10 million value test file:
http://webpki.org/ietf/es6testfile.txt

Although JCS does not (a this stage) represent a standard, the core concept will most likely become a de-facto standard due to its simplicity.

[dilijev]

Node.js uses V8 by default so I'm not surprised the behavior is the same. I wonder if the behavior still matches V8 when using Node with ChakraCore?

[abchatra]

@cyberphone Is it possible to add javascript snippet which fails with console binary such as ch.exe for this?

[abchatra]

I believe this is a bug in precision in parseFloat on edge cases.

[cyberphone]

@abchatra I think the sequence below shows that it is the output formatting of the very last (unprecise) digit that is the problem:

var v1 = 33333333.3333333
console.log(v1);
var v2 = 0.000000036;
console.log(v2);
console.log(v1 + v2);

Chrome, Firefox, Safari: 33333333.333333336 IE11: 33333333.333333335

@dilijev I would assume that node.js with Chakra would exhibit the same behavior.

I solved this issue in my Java implementation by simply taking the V8 number serializer "as is":
https://github.com/cyberphone/openkeystore/tree/master/library/src/org/webpki/json

[cyberphone]

Related issues in .NET:
https://github.com/cyberphone/jsondotnet