Change -INFINITY/+INFINITY/NAN representation to IEEE 754 values

[ghost]

Sent in by Elijah Dorman

In JS, ALL numbers MUST be based on IEEE 754 compliant 64-bit floating point numbers. (see pages 18 and 41 in the official ECMAScript spec below) http://www.ecma-international.org/ecma-262/5.1/Ecma-262.pdf

Note that positive infinity, negative infinity, and NaN are all numbers (and all numbers are 64-bit floats). Reading the IEEE 754 spec shows why (the shown version is the 1985 version. the 2008 version is behind a pay wall unless you want to google for a copy. The '08 version basically extends the spec a little). On page 16 it defines these numbers.

http://kfe.fjfi.cvut.cz/~klimo/nm/ieee754.pdf

[ghost]

I am not convinced that breaking away from the JSON spec (all these values are 'null') is worth the change, but wanted to capture some community feedback first.

[kxepal]

Well, JS != JSON even if they both are defined within same ECMA spec.

Also from http://tools.ietf.org/html/rfc4627#section-2.4 :

Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted.

So if we want to keep transitive relation between UBJSON and JSON this improvement couldn't be acceptable since it leads to information loss (you couldn't get NaN or Infinity value from decoding JSON and couldn't encode it back).

JSON spec is broken for some cases.

P.S. As counter-idea: all these breaking changes are quite reasonable from practice side, especially for binary format. What if we made UBJSON-Ex - non-compatible UBJSON version with JSON, but compatible with original UBJSON? By "compatible" I mean "keeps transitive relation with" e.g. you may convert data between both specs without information loss.

[ghost]

Closing as WONTFIX for the reasons @kxepal laid out and lack of overall interest (don't want these to sit open forever).

Not sure I am onboard with the UBJSON-Ex idea just yet, but maybe down the road :)