From: Morton Goldberg Date: 2007-02-16T07:58:15+09:00 Subject: Re: Converting Bytes to a Negative Integer On Feb 15, 2007, at 11:04 AM, James Edward Gray II wrote: > On Feb 15, 2007, at 9:47 AM, Morton Goldberg wrote: > >> On Feb 14, 2007, at 6:37 PM, James Edward Gray II wrote: >> >>> On Feb 14, 2007, at 5:02 PM, Morton Goldberg wrote: >>> >>>> data = "" >>>> [255, 255, 255, 236].each { |e| data << e } >>>> data # => "\377\377\377\354" >>>> data.unpack('l').first # => -20 >>> >>> Watch what happens when I run the same code: >>> >>> >> data = "" >>> => "" >>> >> [255, 255, 255, 236].each { |e| data << e } >>> => [255, 255, 255, 236] >>> >> data >>> => "\377\377\377\354" >>> >> data.unpack('l').first >>> => -318767105 >> >> I see your point. Many new computers have 64-bit CPUs and we >> should remember that. Also, you want to be sure I, lowly 32-bit >> CPU owner, envy you for having one of these . > > I'll prop you back up then, this isn't a 32 to 64 bit (size) > issue. It's an endian (order) issue: Mea culpa -- I didn't see your point at all. Let's see if I've got it now. 1. Your result couldn't the result of conversion into a 64-bit integer with big-endian byte order, because if that were the case we would see either -20 or a large positive number (if sign extension didn't occur). 2. On my computer (iMac G5), I get [-20].pack('i') # => "\377\377\377\354" [-318767105].pack('i') # => "\354\377\377\377" and [-20].pack('N') # => "\377\377\377\354" [-318767105].pack('N') # => "\354\377\377\377" which shows it's big-endian because both unpack directives produce the same result. 3. On your computer (which I think is also a Macintosh), you would get [-20].pack('i') # => "\354\377\377\377" [-318767105].pack('i') # => "\377\377\377\354" and [-20].pack('N') # => "\377\377\377\354" [-318767105].pack('N') # => "\354\377\377\377" which would show it's little-endian and, presumably, some kind of Intel-based Mac. Do I have it right now? Regards, Morton P.S. But I don't see how this props me back up :-)