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
