Can anyone explain why the literal `0xAABBCCDD_11223344L` cannot exist in Kotlin? Neither can the va...

# getting-started

[mquigley]

Can anyone explain why the literal 0xAABBCCDD_11223344L cannot exist in Kotlin? Neither can the value of Long.MIN_VALUE, which is actually represented by -9223372036854775807L - 1L?

[dalexander]

The first one has to do with how Kotlin handles numeric literals. Basically it assumes that hex literals are positive numbers, and if they can’t fit in the number of bits provided (ie. their leftmost bit is 1) then you run into an issue. The solution for ints is to do something like val someInt = 0xFFFFFFFF.toInt() which is sufficient to make the compiler happy (because 0xFFFFFFFF is a long). It wouldn’t surprise me if longs have an issue though because there’s no primitive type to cast down from.

[mquigley]

Yeah in longs there is no alternative. I’m doing something silly right now - java.lang.Long.parseUnsignedLong("AABBCCDD11223344", 16)

[dalexander]

That’s unfortunate 😞 For what it’s worth they are considering adding some sort of unsigned types in the future which will make certain kinds of bit manipulation easier.

[Ruckus]

Does "AABBCCDD11223344".toLong(16) work?

[mquigley]

No 😞

Exception in thread “main” java.lang.NumberFormatException: For input string: “AABBCCDD11223344"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:592)

[Ruckus]

Lame 😞

[kingsley]

@mquigley maybe you could make an extension property to wrap the noise. That would at least look a bit more sane. Something like:

val String.UL: Long 
  get() = java.lang.Long.parseUnsignedLong(this, 16)

So, you could use it like:

"AABBCCDD11223344".UL

[mquigley]

very good idea