0xFFFFFFFF convert to int32 result in 4294967295?

[khchen]

import typetraits
proc `$`*[T](some:typedesc[T]): string = name(T)

proc test(x: int64) = echo x
const
  A = 0xFFFFFFFF'i32 #'
  B = 0xFFFFFFFF.int32

test(A)
test(B)

echo "type of B is ", B.type
echo "B > int32.high ? ", B > int32.high

Nim Compiler Version 0.16.0
output is the same on both 32/64 bit mode:
-1
4294967295
type of B is int32
B > int32.high ? true

[krux02]

I think that A should raise a compile error, or at least a warning. 0xFFffFFff is in my opinion not a valid int32 literal. uint32 would be ok though.

B should behave like A currently does.

[Araq]

A should produce -1, that's what was asked for. B should produce a compiletime error.

[khchen]

I think A is ok, it use a hex format to represent a -1 value. The type must be int32 becasue I specify it.
B has the problem. It do a "int64 to int32" convert. However, the convert should raise a error.
(0xFFFFFFFF without suffix always generate a int64 type value on both 32/64 bit)

[khchen]

We answer the question at the same time, lol.

[krux02]

I don't think B should produce a compile time error. When I call int32 on an int64 at runtime, I would also not expect a runtime error.

@khchen I recently learned how this is possible to happen. In the compiler all integers are stored as value of BiggestInt. This value is tagged with the explicit type, in this case int32, but that does not limit it to be out of the range of an int32. Operations are still on BiggestInt range. int32 does not wrap around at compile time in the 32bit range.

[khchen]

Here is a similar problem:

import typetraits

proc `$`*[T](some:typedesc[T]): string = name(T)

const
  A = 0xFFFFFFFE'u32 #'
  B = not A

echo A.type
echo B.type
echo B.int64
# echo B # Compile Error: cannot convert -4294967295 to uint64
echo cast[uint32](B)

output:
uint32
uint32
-4294967295
1

B is already uint32, however, I need use cast[uint32] to get the correct value.

[khchen]

Another type problem:

import typetraits
proc `$`*[T](some:typedesc[T]): string = name(T)
const
  A = -2147483648
  B = 2147483647
  C = -2147483648.int

echo A.type # int64, why not just int?
echo B.type # int, correct
echo C.type # int, correct

A literal should be a int type if it is possible.

[krux02]

I think this bug should get a tag integer-literals-are-special. Integer literals are treated specially in Nim, and there are known problems with it.

[markus-oberhumer]

See also issue #6829.

[Araq]

Now it fails to compile with "temp.nim(8, 17) Error: 4294967295 can't be converted to int32" which is good.

And the other example works as expected now.