3 ms·

> If JSON is specified to only represent numbers that fit within a JavaScript double, It isn't / doesn't make that restriction. For example, 100000000000000

> If JSON is specified to only represent numbers that fit within a JavaScript double, It isn't / doesn't make that restriction. For example, 10000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000 is a valid JSON value. Python will decode it to an integer with the equivalent value; JavaScript will decode it to "Infinity", as it exceeds the limits of Number. (Despite nowadays having a bigint type that could represent it.) It is possible to write a JSON parser in JavaScript that would handle decoding large numbers to BigInts. Most people just don't bother, as it's pretty rare to need to go above the 2 * 53 limit of JS's number.

woodruffw 6y ago
You're absolutely right about that, and that's even worse than I had remembered! Not only can two parsers not be trusted to have equivalent acceptance contracts (in the absence of bugs), but they can correctly disagree on the acceptance of a single input! The actual RFC language[1]: > This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. [1]: https://tools.ietf.org/html/rfc7159#section-6 https://tools.ietf.org/html/rfc7159#section-6
dang 6y ago
I added some newlines to your number because it was borking the page layout. Sorry; it's our bug.
- DonHopkins 6y ago
  Not so liberal about what you accept, ehe? ;)
  - dang 6y ago
    We try to make up for it in the extreme narrowness of what we produce.
    - DaiPlusPlus 6y ago
      Are you hiring? <_<

woodruffw 6y ago

You're absolutely right about that, and that's even worse than I had remembered! Not only can two parsers not be trusted to have equivalent acceptance contracts (in the absence of bugs), but they can correctly disagree on the acceptance of a single input! The actual RFC language[1]: > This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. [1]: https://tools.ietf.org/html/rfc7159#section-6 https://tools.ietf.org/html/rfc7159#section-6

dang 6y ago

I added some newlines to your number because it was borking the page layout. Sorry; it's our bug.

DonHopkins 6y ago
Not so liberal about what you accept, ehe? ;)
- dang 6y ago
  We try to make up for it in the extreme narrowness of what we produce.
  - DaiPlusPlus 6y ago
    Are you hiring? <_<