[Development] JSON 64 bit int

[Giuseppe D'Angelo]

Il 11/02/2015 16:11, Marc Mutz ha scritto:
> If Qt produces 64-bit integers in its JSON output, then the next bug report
> will (probably rightfully) be that Qt's JSON output cannot be read by some
> JavaScript library X.

Note that it's perfectly legal, and a "feature" of JSON:

https://tools.ietf.org/html/rfc7158#section-6

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

So Qt is totally right at accepting an arbitrary range, and another JS 
library would be right at not accepting the numbers that Qt outputs.

But even with this total mis-specification (just say it's IEEE754 
doubles and make JS a normative reference already!), I'd rather not go 
down that road and avoid integer-based APIs for QJsonValue (to the point 
of deprecating the existing qint64 constructor; I won't make that call 
though). And, with the reasonable assumption that the accepted values 
are JS numbers (minus NaN/infinity), which nowadays is probably the 
equivalent of saying that an int is 32 bits, then sending out 64-bit ids 
as numbers is a flaw that has to be corrected on sender's side.

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4048 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150211/1b013d39/attachment.bin>