All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000
Date: Mon, 23 May 2011 10:24:07 -0500	[thread overview]
Message-ID: <4DDA7C17.6020208@codemonkey.ws> (raw)
In-Reply-To: <20110523151948.GJ27503@amd.home.annexia.org>

On 05/23/2011 10:19 AM, Richard W.M. Jones wrote:
> On Mon, May 23, 2011 at 10:07:21AM -0500, Anthony Liguori wrote:
>> On 05/23/2011 09:29 AM, Markus Armbruster wrote:
>>> Anthony Liguori<anthony@codemonkey.ws>   writes:
>>>
>>> JavaScript's implementation of JSON sets limits on the range of numbers,
>>> namely they need to fit into IEEE doubles.
>>>
>>> Our implementation sets different limits.  IIRC, it's something like
>>> "numbers with a fractional part or an exponent need to fit into IEEE
>>> doubles, anything else into int64_t."  Not exactly the acme of elegance,
>>> either.  But it works for us.
>>
>> In order to be compatible with JavaScript (which I think is
>> necessary to really satisfy the spec), we just need to make sure
>> that our integers are represented by at least 53-bits (to enable
>> signed integers) and critically, fall back to floating point
>> representation to ensure that we round instead of truncate.
>
> The problem is to be able to send 64 bit memory and disk offsets
> faithfully.  This doesn't just fail to solve the problem, it's
> actually going to make it a whole lot worse.
>
> I don't agree with you that whatever the JSON standard (RFC) doesn't
> specify must be filled in by reading Javascript/ECMA.

"  It is derived from the object
    literals of JavaScript, as defined in the ECMAScript Programming
    Language Standard, Third Edition [ECMA]."

> If this is so
> important, it's very odd that it doesn't mention this fallback in the
> RFC.  If you read the RFC alone then it's pretty clear (to me) that it
> leaves limits up to the application.

If it's left up to the application, doesn't that mean that we can't ever 
send 64-bit memory/disk faithfully?

Because a client would be allowed to represent integers as signed 32-bit 
numbers.

Fundamentally, we need to ask ourselves, do we want to support any JSON 
client or require JSON libraries explicitly written for QEMU?

What I suggested would let us work with any JSON client, but if clients 
loose precision after 53-bits, those clients would not work well with QEMU.

The alternative approach is to be conservative and only use 32-bit 
integers and represent everything in two numbers.

Regards,

Anthony Liguori

>
> Rich.
>

  reply	other threads:[~2011-05-23 15:24 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
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 [this message]
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=4DDA7C17.6020208@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --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.