On 03-Aug-2015 10:56, Sönke Ludwig wrote:
Am 02.08.2015 um 19:14 schrieb Dmitry Olshansky:
Actually JSON is defined as subset of EMCASCript-262 spec hence it may
not ciontain anything other 64-bit5 IEEE-754 numbers period.
See:
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-terms-and-definitions-number-value
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-types-number-type
Anything else is e-hm an "extension" (or simply put - violation of
spec), I've certainly seen 64-bit integers in the wild - how often true
big ints are found out there?
If no one can present some run of the mill REST JSON API breaking the
rules I'd suggest demoting BigInt handling to optional feature.
This is not true. Quoting from ECMA-404:
JSON is a text format that facilitates structured data interchange
between all programming languages. JSON
is syntax of braces, brackets, colons, and commas that is useful in
many contexts, profiles, and applications.
JSON was inspired by the object literals of JavaScript aka
ECMAScript as defined in the ECMAScript
Language Specification, third Edition [1].
It does not attempt to impose ECMAScript’s internal data
representations on other programming languages. Instead, it shares a
small subset of ECMAScript’s textual
representations with all other programming languages.
JSON is agnostic about numbers. In any programming language,
there can be a variety of number types of
various capacities and complements, fixed or floating, binary or
decimal. That can make interchange between
different programming languages difficult. JSON instead offers
only the representation of numbers that
humans use: a sequence of digits. All programming languages know
how to make sense of digit sequences
even if they disagree on internal representations. That is enough to
allow interchange.
Hm about 5 solid pages and indeed it leaves everything unspecified for
extensibility so I stand corrected.
Still I'm more inclined to put my trust in RFCs, such as the new one:
http://www.ietf.org/rfc/rfc7159.txt
Which states:
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. A JSON
number such as 1E400 or 3.141592653589793238462643383279 may indicate
potential interoperability problems, since it suggests that the
software that created it expects receiving software to have greater
capabilities for numeric magnitude and precision than is widely
available.
Note that when such software is used, numbers that are integers and
are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
sense that implementations will agree exactly on their numeric
values.
And it implies setting limits on everything:
9. Parsers
A JSON parser transforms a JSON text into another representation. A
JSON parser MUST accept all texts that conform to the JSON grammar.
A JSON parser MAY accept non-JSON forms or extensions.
An implementation may set limits on the size of texts that it
accepts. An implementation may set limits on the maximum depth of
nesting. An implementation may set limits on the range and precision
of numbers. An implementation may set limits on the length and
character contents of strings.
Now back to our land let's look at say rapidJSON.
It MAY seem to handle big integers:
https://github.com/miloyip/rapidjson/blob/master/include/rapidjson/internal/biginteger.h
But it's used only to parse doubles:
https://github.com/miloyip/rapidjson/pull/137
Anyhow the API says it all - only integers up to 64bit and doubles:
http://rapidjson.org/md_doc_sax.html#Handler
Pretty much what I expect by default.
And plz-plz don't hardcode BitInteger in JSON parser, it's slow plus it
causes epic code bloat as Don already pointed out.
--
Dmitry Olshansky
