From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOhhd-0006Zv-Ly for qemu-devel@nongnu.org; Mon, 23 May 2011 22:50:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOhhX-0001DF-BJ for qemu-devel@nongnu.org; Mon, 23 May 2011 22:50:37 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:34008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOhhX-0001D8-3Y for qemu-devel@nongnu.org; Mon, 23 May 2011 22:50:31 -0400 Received: by yxk8 with SMTP id 8so2854243yxk.4 for ; Mon, 23 May 2011 19:50:30 -0700 (PDT) Message-ID: <4DDB1CF4.5060409@codemonkey.ws> Date: Mon, 23 May 2011 21:50:28 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110520180331.GA21837@amd.home.annexia.org> <4DD6AEB9.6060506@codemonkey.ws> <20110523130411.GR24143@redhat.com> <4DDA620F.1090308@codemonkey.ws> <20110523134021.GT24143@redhat.com> <4DDA663F.30907@codemonkey.ws> <4DDA7829.5090103@codemonkey.ws> <20110523151948.GJ27503@amd.home.annexia.org> <20110523230222.GL969@shareable.org> In-Reply-To: <20110523230222.GL969@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Use a hex string List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Markus Armbruster , Luiz Capitulino , "Richard W.M. Jones" , qemu-devel@nongnu.org On 05/23/2011 06:02 PM, Jamie Lokier wrote: > Richard W.M. Jones wrote: >> 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. > > Such offsets would be so much more readable in hexadecimal. > > So why not use a string "0xffff800012340000" instead? This doesn't change the fundamental issue here. Javascript's internal representation for integers isn't 2s compliment, but IEEE794. This means the expectations about how truncation/overflow is handled is fundamentally different. Regards, Anthony Liguori > > That is universally Javascript compatible as well as much more > convenient for humans. > > Or at least, *accept* a hex string wherever a number is required by > QMP (just because hex is convenient anyway, no compatibility issue), > and *emit* a hex string where the number may be out of Javascript's > unambiguous range, or where a hex string would make more sense anyway. > > -- Jamie >