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.

▲

q3k 2 days ago | parent | next [-]

Have a read through RFC7159 or 8259 and despair.

> This specification allows implementations to set limits on the range and precision of numbers accepted

JSON is a terrible interoperability standard.

▲

matja 2 days ago | parent [-]

So a JSON parser that cannot store a 2 is technically compliant? :(

▲

reichstein 2 days ago | parent | next [-]

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.

	▲	deepsun 17 hours ago \| parent \| next [-]
		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.
	▲	tsimionescu a day ago \| parent \| prev [-]
		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.

▲

q3k 2 days ago | parent | prev [-]

Yep. Or one that parses it into a 7 :)

▲

chasd00 2 days ago | parent | next [-]

> Or one that parses it into a 7 :)

if it's known and acceptable that LLMs can hallucinate arguments to an API then i don't see how this isn't perfectly acceptable behavior either.

▲

kevingadd 2 days ago | parent | prev [-]

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"

	▲	xeromal 2 days ago \| parent [-]
		That sounds awful. lol

▲

kens 2 days ago | parent | prev [-]

> 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.

▲

alterom a day ago | parent | next [-]

>> 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.

Orwell has much to say about either.

_____

¹https://www.orwellfoundation.com/the-orwell-foundation/orwel...

	▲	NooneAtAll3 19 hours ago \| parent [-]
		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.

▲

NooneAtAll3 19 hours ago | parent | prev | next [-]

Aren't {X}? -> isn't it true that {X}?

{X} = JSON parsers technically [are] not following the standard if {reason}

{reason} = [JSON parsers] don't reliably store a number that {what kind of number?}

{what kind of number} = number that is not representable by a IEEE754 double precision float

seems simple

▲

umanwizard 2 days ago | parent | prev [-]

“The standard technically requires that JSON parsers reliably store numbers, even those that are not representable by an IEEE double”.

(It seems this claim is not true, but at least that’s what the sentence means.)