From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Richard W.M. Jones" <rjones@redhat.com>,
qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000
Date: Mon, 23 May 2011 16:41:16 +0100 [thread overview]
Message-ID: <20110523154116.GZ24143@redhat.com> (raw)
In-Reply-To: <4DDA7736.9010904@codemonkey.ws>
On Mon, May 23, 2011 at 10:03:18AM -0500, Anthony Liguori wrote:
> On 05/23/2011 09:14 AM, Daniel P. Berrange wrote:
> >On Mon, May 23, 2011 at 08:45:54AM -0500, Anthony Liguori wrote:
> >>On 05/23/2011 08:40 AM, Daniel P. Berrange wrote:
> >>>On Mon, May 23, 2011 at 08:33:03AM -0500, Anthony Liguori wrote:
> >>>>On 05/23/2011 08:04 AM, Daniel P. Berrange wrote:
> >>>>>On Fri, May 20, 2011 at 01:11:05PM -0500, Anthony Liguori wrote:
> >>>>>>On 05/20/2011 01:03 PM, Richard W.M. Jones wrote:
> >>>>>>>
> >>>>>>>There seem to be a few unsafe uses of strto* functions. This patch
> >>>>>>>just fixes the one that affects me :-)
> >>>>>>
> >>>>>>Sending an integer of this size is not valid JSON.
> >>>>>>
> >>>>>>Your patch won't accept negative numbers, correct?
> >>>>>>
> >>>>>>JSON only supports int64_t.
> >>>>>
> >>>>>That's not really true. JSON supports arbitrarily large numbers
> >>>>>& integers.
> >>>>
> >>>>Try the following snippet in your browser:
> >>>>
> >>>><html>
> >>>><head>
> >>>><script type="text/javascript">
> >>>>alert(9223372036854775807);
> >>>></script>
> >>>></head>
> >>>></html>
> >>>>
> >>>>The actual value of the alert will surprise you :-)
> >>>>
> >>>>Integers in Javascript are actually represented as doubles
> >>>>internally which means that integer constants are only accurate up
> >>>>to 52 bits.
> >>>>
> >>>>So really, we should cap integers at 32-bit :-/
> >>>>
> >>>>Have I mentioned recently that I really dislike JSON...
> >>>
> >>>NB, I am distinguishing between JSON the generic specification and
> >>>JSON as implemented in web browsers. JSON the specification has *no*
> >>>limitation on integers. Any limitation, like the one you demonstrate,
> >>>is inherantly just specific to the implementation.
> >>
> >>No, EMCA is very specific in how integers are handled in JavaScript.
> >>Every implementation of JavaScript is going to exhibit this
> >>behavior.
> >>
> >>The JSON specification lack of specificity here I think has to be
> >>interpreted as a deferral to the EMCA specification.
> >
> >The EMCA spec declares that integers upto 52-bits can be stored
> >without loosing precision. This doesn't forbid sending of 64-bit
> >integers via JSON. It merely implies that when parsed into a
> >EMCA-Script object you'll loose precision. So this doesn't mean that
> >QEMU has to throw away the extra precision when parsing JSON, nor
> >do client apps have to throw away precision when generating JSON
> >for QEMU. Both client& QEMU can use a full uint64 if desired.
>
> Thinking more carefully about this, I think the following rule is important:
>
> 1) Integers that would cause overflow should be treated as double
> precision floating point numbers.
>
> 2) A conforming implementation must support integer precision up to
> 52-bit signed integers.
>
> I think this is valid because the string:
>
> 9223372036854775808
>
> Is a representation of:
>
> 9223372036854776e3
>
> Both are equivalent representations of the same number. So we can
> send and accept arbitrarily large integers provided that we always
> fallback to representing integers as double precision floating
> points if the integer would otherwise truncate.
>
> I think this means we need to drop QFloat and QInt, add a QNumber,
> and then add _from_uint64/to_uint64 and _from_double/to_double.
As long as QNumber is using the string as its internal representation,
and only converting to a more limited integer/float format at time of
use, this sounds workable.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2011-05-23 15:41 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-20 18:03 [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000 Richard W.M. Jones
2011-05-20 18:11 ` Anthony Liguori
2011-05-20 18:36 ` Richard W.M. Jones
2011-05-20 18:37 ` Richard W.M. Jones
2011-05-20 18:47 ` Richard W.M. Jones
2011-05-20 21:19 ` Richard W.M. Jones
2011-05-23 13:04 ` Daniel P. Berrange
2011-05-23 13:33 ` Anthony Liguori
2011-05-23 13:39 ` Richard W.M. Jones
2011-05-23 13:40 ` Daniel P. Berrange
2011-05-23 13:45 ` Anthony Liguori
2011-05-23 14:14 ` Daniel P. Berrange
2011-05-23 15:03 ` Anthony Liguori
2011-05-23 15:41 ` Daniel P. Berrange [this message]
2011-05-23 14:20 ` Markus Armbruster
2011-05-23 13:50 ` Anthony Liguori
2011-05-23 14:02 ` Luiz Capitulino
2011-05-23 14:06 ` Anthony Liguori
2011-05-23 14:24 ` Daniel P. Berrange
2011-05-23 14:29 ` Markus Armbruster
2011-05-23 14:32 ` Daniel P. Berrange
2011-05-23 15:07 ` Anthony Liguori
2011-05-23 15:19 ` Richard W.M. Jones
2011-05-23 15:24 ` Anthony Liguori
2011-05-23 15:29 ` Richard W.M. Jones
2011-05-23 15:59 ` Anthony Liguori
2011-05-23 16:06 ` Daniel P. Berrange
2011-05-23 15:38 ` Daniel P. Berrange
2011-05-23 16:18 ` Markus Armbruster
2011-05-23 16:37 ` Anthony Liguori
2011-05-24 6:26 ` Markus Armbruster
2011-05-23 23:02 ` [Qemu-devel] Use a hex string (was: [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000) Jamie Lokier
2011-05-24 2:50 ` [Qemu-devel] Use a hex string Anthony Liguori
2011-05-24 5:30 ` Jamie Lokier
2011-05-23 13:38 ` [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000 Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110523154116.GZ24143@redhat.com \
--to=berrange@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.