Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float?
It's a shame JSON parsers usually default to performance rather than correctness, by using bignums for numbers.
JSON is a text format. A parser must recognize the text `2` as a valid production of the JSON number grammar.
Converting that text to _any_ kind of numerical value is outside the scope of the specification.
(At least the JSON.org specification, the RFC tries to say more.)
As a textural format, when you use it for data interchange between different platforms, you should ensure that the endpoints agree on the _interpretation_, otherwise they won't see the same data.
Again outside of the scope of the JSON specification.
The more a format restricts, the more useful it is. E.g. if a format allows pretty much anything and it's up to parsers to accept or reject it, we may as well say "any text file" (or even "any data file") -- it would allow for anything.
Similarly to a "schema-less" DBMS -- you will still have a schema, it will just be in your application code, not enforced by the DBMS.
JSON is a nice balance between convenience and restrictions, but it's still a compromise.
A JSON parser has to check if a numeric value is actually numeric - the JSON {"a" : 123456789} is valid, but {"a" : 12345678f} is not. Per the RFC, a standards-compliant JSON parser can also refuse {"a": 123456789} if it considers the number is too large.
I once debugged a production issue that boiled down to "A PCI compliance .dll was messing with floating point flags, causing the number 4 to unserialize as 12"
> Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float?
That sentence has four negations and I honestly can't figure out what it means.
>> Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float?
>That sentence has four negations and I honestly can't figure out what it means.
This example is halfway as bad as the one Orwell gives in my favorite essay, "Politics the the English Language"¹.
Compare and contrast:
>I am not, indeed, sure whether it is not true to say that the Milton who once seemed not unlike a seventeenth-century Shelley had not become, out of an experience ever more bitter in each year, more alien (sic) to the founder of that Jesuit sect which nothing could induce him to tolerate.
that Orwell quote can be saved a lot by proper punctuation
I am not, indeed, sure*,* whether it is not true to say that the Milton *(*who once seemed not unlike a seventeenth-century Shelley*)* had not become *-* out of an experience *-* ever more bitter in each year, more alien (sic) to the founder of that Jesuit sect*,* which nothing could induce him to tolerate.
Has the proper punctuation allowed you to see that there's an extra negation there that makes the sentence say the exact opposite of what the author intended it to say?
It's a shame JSON parsers usually default to performance rather than correctness, by using bignums for numbers.