From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOkCq-0001Hp-Ht for qemu-devel@nongnu.org; Tue, 24 May 2011 01:31:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOkCp-00076b-Hl for qemu-devel@nongnu.org; Tue, 24 May 2011 01:31:00 -0400 Received: from mail2.shareable.org ([80.68.89.115]:41497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOkCp-00076P-CP for qemu-devel@nongnu.org; Tue, 24 May 2011 01:30:59 -0400 Date: Tue, 24 May 2011 06:30:57 +0100 From: Jamie Lokier Message-ID: <20110524053057.GM969@shareable.org> References: <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> <4DDB1CF4.5060409@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DDB1CF4.5060409@codemonkey.ws> Subject: Re: [Qemu-devel] Use a hex string List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Markus Armbruster , Luiz Capitulino , "Richard W.M. Jones" , qemu-devel@nongnu.org Anthony Liguori wrote: > 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. No, the point is it's a string so Javascript numerics doesn't come into it, no overflow, no truncation, no arithmetic. Every program that wants to handle them handles them as a *string-valued attribute* externally, and whatever representation it needs for a particular attribute internally. (Just as enum values are represented with strings too). In the unlikely event that someone wants to do arithmetic on these values *in actual Javascript*, it'll be tricky for them, but the representation doesn't have much to do with that. -- Jamie