But why is it in octal? It should be 0xFF, not 0xAD
Binary data handling bug
Started by columna1, Dec 17 2013 05:59 PM
22 replies to this topic
#21
Posted 16 June 2015 - 03:55 PM
#22
Posted 16 June 2015 - 08:50 PM
MindenCucc, on 16 June 2015 - 03:55 PM, said:
But why is it in octal? It should be 0xFF, not 0xAD
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
Posted 17 June 2015 - 02:06 AM
MindenCucc, 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











