• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

why won't this shift work?

Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Got a weird case here. If I write the code with an extra step and variable, it works, but won't otherwise. Basically, I am reading binary code out of a file, and the longs are listed backwards(correct term escapes me right now).
For example, in the file 11 15 80 80 should be read as 80 80 15 11. so I have the following code
The bytes in question are in a byte array (vHeader) and improvements is the long that will hold the complete value.

This produces the correct output -
improvements = 801511
improvements = 80801511

produces the incorrect output:
improvements = 801511
improvements = ffffffff80801511
what is the difference?
[ March 08, 2002: Message edited by: Scott Hiett ]
Posts: 2205
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The term that escapes you is "endian-ness". Your longs are stored as little-endian values, where the least-significant-byte (LSB) is written and thus read first.
Is this data coming from someplace external to your program? If you're writing it from java you should be able to write and read in the same order.
Anyway, the problem you have is with the bit size of the value you shift. Simply put, if you shift a 1 bit into the high-order position of an INT (bit#32), that value becomes negative. If you shift a 1 bit into the same position (32) of a LONG, it's just really big value, but it's not negative.
long tmplong = vHeader[currPointer++]&0xff;
improvements += (tmplong << 24);
This code is shifting bits in a LONG value. Since a long is 64 bits, you aren't going to be shifting anything into the sign-bit of this number, so you can't change the sign with this code.
improvements += (vHeader[currPointer++]&0xff) << 24;
Here you are shifting an INT 24 times. If bit #8 happens to be a 1, when this shift is done, you've just changed the sign of your value, effectively experiencing an underflow.
vHeader[] is a byte array, and you bit-wise AND it with an INT literal, so the left-hand operand is widened to an INT, and the type of the result is an INT. This INT is then left-shifted 24 times.
That's the difference between the two cases.
    Bookmark Topic Watch Topic
  • New Topic