[Development] JSON 64 bit int

[Marc Mutz]

On Wednesday 11 February 2015 17:42:54 Giuseppe D'Angelo wrote:
> 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.

There are two different topics here: how to best represent larger-than-double 
integers or floats in JSON and whether Qt should support them.

I read the above as an instance of Postel's Law: Interoperable software might 
not want to create numbers that JS can't parse (in the original sense, with 
eval()), but it doesn't hurt to allow larger numbers.

Of course, at the end of the day, it's the job of the API user to conform to 
the spec, even though, if emails and json are any indicator, they are not good 
at that.

That said, Bo's customer is apparently right, according to the spec.

The interesting part is what Qt should do about it. Postel's Law clearly asks 
for accepting (even invalid) input as long as its meaning is clear. Clearly, 
that is the case for larger-than-double numbers. So, by Postel's Law, Qt 
should strive to support them. If you apply the law to the API side of QtJSON, 
then it should do so even for writing. So Bo has a valid point.

If long double was any useful (apparently it's no larger than double on 
Windows), we could use that, but as it stands, that would be pointless.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions