Jump to content




Binary data handling bug


  • You cannot reply to this topic
22 replies to this topic

#21 MindenCucc

  • Members
  • 179 posts
  • Location/home/marcus/

Posted 16 June 2015 - 03:55 PM

But why is it in octal? It should be 0xFF, not 0xAD

#22 ardera

  • Members
  • 503 posts
  • LocationGermany

Posted 16 June 2015 - 08:50 PM

View PostMindenCucc, on 16 June 2015 - 03:55 PM, said:

But why is it in octal? It should be 0xFF, not 0xAD
I think it's not uncommon to specify character codes as octal numbers. In many ASCII tables, the octal value is given too. Why is that? I don't know.

I think this bug is actually 2 bugs. The first one is the one ElvishJerrico already said: LuaJ uses UTF-8, so this corrupts bytes larger than 127. This means that the byte after the byte > 127 is consumed, and doesn't appear in the Java String. I had issues with that before, bytecode dumping is problematic because of this. (See Here)
The second one is the one MindenCucc explained, although I honestly don't really think that this second bug causes the most problems.

Edited by ardera, 17 June 2015 - 04:19 AM.


#23 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 17 June 2015 - 02:06 AM

View PostMindenCucc, on 16 June 2015 - 03:55 PM, said:

But why is it in octal? It should be 0xFF, not 0xAD

If you wanted 0xFF, you would specify \377, or \u00FF. Java uses octal escapes because C does it too.

https://docs.oracle....html#jls-3.10.6





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users