Hard to understand decompile result

Support
1

i had wanted to know decompile process, so i wrote simple code then decompile it.
below is my code

fun main() {
    var unusedIntValue: Int = 5
    var unusedLargeIntValue: Int = 50000
}

then result is

public final class MainKt {
   public static final void main() {
      int unusedIntValue = true;
      int unusedLargeIntValue = '썐';
   }

   // $FF: synthetic method
   public static void main(String[] var0) {
      main();
   }
}

for a while, i figuared out “쌘” mean 50000 on bytecode
but still i cant understand why unused int value become “true” even considering true actually 1
Long, String, Boolean, Integer, etc… value is correct but only int type become boolean value.

anyone give me any clue or detail about it?

2

Strange I get the same result. Intellij Decompiler (bothe kotlin 1.3.61 and 1.3.7-eap). I took a look at the bytecode which looks exactly like what you’d expect from your source:

L0
    LINENUMBER 2 L0
    ICONST_5  // load const 5 onto stack
    ISTORE 0   // store top stack value at variable 0
L1
    LINENUMBER 3 L1
    LDC 50000  // load const 50000 onto stack
    ISTORE 1    // store top stack value at variable 1

Something must be up with the decompiler. Adding println(unusedIntValue) at least changes true back to 5, no such luck for the 50000.
My guess is that the decompiler got a bit confused since neither value was used. That way 5 and true are pretty much the same, I guess. Also technically every value not equal to 0 is normally considered true… I don’t know.
And you already figured out that 썐 is the unicode character with codepoint 50000 or U+C350. At a bytecode level there is no difference between the character symbol and the number so while this isn’t allowd in kotlin, this is valid java and sets the int to 50000. Still you’d think the decompiler use an integer literal instead of a unicode character for an int.

My experience with the build in decompiler is that while it is quite good normally you shouldn’t expect perfect code as a result and you definetly won’t be able to compile it again.

3

A key element to remember is that as far as JVM bytecode is concerned there are only 4 full primitive values; int, long, float and double. All the other ones are a variant of int. Booleans are particularly special in that any value other than 0 counts as true. The other primitives can have specific arrays, different function signatures, and there are some operations for truncation etc. but otherwise a single word number is a single word (32bit) number. Given that code the decompiler needs to guess what the type is by looking at how it is used. In this example there is no such context so it just has to take a guess.

What is strange here is that it partially uses the debug information for the variable name and type, but doesn’t use it for the corresponding constant expression.