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