3 ms·
So a JSON parser that cannot store a 2 is technically compliant? :(
by matja 1y ago
So a JSON parser that cannot store a 2 is technically compliant? :(
- q3k 1y agoYep. Or one that parses it into a 7 :)
- kevingadd 1y agoI 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 1y agoThat sounds awful. lol
- chasd00 1y ago> 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.
- reichstein 1y agoJSON 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.
- tsimionescu 1y agoA 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.
- deepsun 1y agoThe 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.