Unsigned integer parsing problem

[markus-oberhumer]

Unsigned integer parsing problem:

when sizeof(int) == 8:
  var a = 18446744073709551615'u64
  var b = 18446744073709551615'u     # FAILS TO COMPILE

[Araq]

That's not a bug. Unsigned is 32 bits depending on the target and we encourage you to write platform independent code.

[markus-oberhumer]

This argument does not make much sense, though:

when sizeof(int) == 8:
  var x =  9223372036854775807'i64
  var y =  9223372036854775807       # WORKS
  var a = 18446744073709551615'u64
  var b = 18446744073709551615'u     # FAILS TO COMPILE

[markus-oberhumer]

Also:

when sizeof(int) == 8:
  var x = 0xffffffffffffffff'u64
  var y = 0xffffffffffffffff'u       # WORKS !
  var a = 18446744073709551615'u64
  var b = 18446744073709551615'u     # FAILS TO COMPILE

[Araq]

Like it or not, they all adhere to the spec that at least exists in my head. The type of an integer literal is int unless it's range doesn't fit an int32 then it is an int64. Hexadecimal numbers are ambiguous and not checked. 'u is explicitly asking for uint with cannot hold a 64bit number.

[markus-oberhumer]

Well, that specification is surprising, to say the least:

when sizeof(int) == 8:
  var x: int = 9223372036854775807.int
  var y: int = 9223372036854775807      # DOES NOT COMPILE

[markus-oberhumer]

[EDIT: created issue #6838 for this]

This problem might be unrelated - I can open a new issue if you prefer:

when sizeof(int) == 8:
  var a   = 18446744073709551615'u64.uint
  const b = 18446744073709551615'u64.uint

  doAssert(a is uint)
  doAssert(b is uint)
  doAssert(a == b)

  echo a
  echo b # DOES NOT COMPILE

[Araq]

Well, that specification is surprising, to say the least.

Come up with a better one, what's the alternative?

[markus-oberhumer]

I don't know enough of Nim's internals to suggest a workable alternative, but stumbling over things like setting lastOrd(tyUInt64) to 0x7FFFFFFFFFFFFFFF'i64 makes me realize that the intergral type system has grown and was not designed upfront.

[markus-oberhumer]

Here is an interesting variation of the problem:

when sizeof(int) == 8:
  doAssert         0x7fffffff is int
  doAssert         0x80000000 is int64
  doAssert         0xffffffff is int64
  doAssert 0x8000000000000000 is int64
  doAssert 0xffffffff00000000 is int64
  doAssert 0xffffffff7fffffff is int64
  doAssert 0xffffffff80000000 is int      # int and NOT int64 !
  doAssert 0xffffffffffffffff is int      # int and NOT int64 !

[Araq]

But stumbling over things like setting lastOrd(tyUInt64) to 0x7FFFFFFFFFFFFFFF'i64 makes me realize that the intergral type system has grown and was not designed upfront.

Irrelevant code, high(uint64) is caught earlier in the frontend and doesn't compile. It was designed in the sense we took multiple iterations over it, every one breaking someone's code, no iteration that produced an "intuitive" design because such a thing doesn't exist with unsigned numbers.

[markus-oberhumer]

After looking at getNumber() in compiler/lexer.nim I can spot even more problems:

#oAssert 0x7fffffffffffffff'i32 != 0   # number out of range - good
  
doAssert 0x8000000000000000'i32 == 0   # SHOULD NOT COMPILE
doAssert 0xffffffff00000000'i32 == 0   # SHOULD NOT COMPILE
doAssert 0xffffffff7fffffff'i32 != 0   # SHOULD NOT COMPILE
doAssert 0xffffffff80000000'i32 != 0   # SHOULD NOT COMPILE
doAssert 0xffffffffffffffff'i32 != 0   # SHOULD NOT COMPILE

[krux02]

I suggested once that the type int should be just an alias for either int64 or int32. This would at least fix the problem that the literal is sometimes int and sometimes int64.

But when complaining about the integer type it is important to take into account that integer literals are not the same as integers. Integer literal are automatically downcasted to a smaller type, if a compile time check ensures no over or underflow.

[krux02]

this does work now.