#778 Conversion bug in : Hex (&h ...) to Ulongint/Longint

[stephanbrunker]

Hello,

I just stubled over a bug in the conversion of hex values to Ulongint or Longint Data Types in the 32-bit version of the compiler. If the 32. bit is set and the upper 32 bits are empty, the upper 32 bits are replaced with &FFFFFFFF:

dim as ulongint a
a = &h0000000000000001
print hex(a,16),a
a = &h0000000070000001
print hex(a,16),a
a = &h0000000080000001
print hex(a,16),a
a = &h80000001
print hex(a,16),a
a = &h8000000080000001
print hex(a,16),a
a = &h0000000180000001
print hex(a,16),a

[dkl]

The default data type for integer number literals is Integer, that's signed 32bit on 32bit. Then if the sign bit is set, it will be sign-extended when converted to 64bit, this is normal.

It can be avoided by adding a number literal suffix like u or [u]ll, saying that the number is a UInteger (then it will do zero-extension instead of sign-extension) or a [U]LongInt (then there's no extension done at all):

print &h80000000  '' Integer
print &h80000000u  '' UInteger
print &h80000000ll  '' LongInt
print &h80000000ull  '' ULongInt
print "--"
print culngint(&h80000000)
print culngint(&h80000000u)
print culngint(&h80000000ll)
print culngint(&h80000000ull)
print "--"
print clngint(&h80000000)
print clngint(&h80000000u)
print clngint(&h80000000ll)
print clngint(&h80000000ull)

[fxm (freebasic.net)]

But that works when using a decimal literal without suffix:

dim as ulongint a
a = &h80000000
print hex(a,16), a
a = 2147483648
print hex(a,16), a

When using an hexadecimal literal without suffix, is the implicit conversion for assignment is distorted by that first conversion to 32bit?
Why that first conversion?

[dkl]

Integer number literals can be implicitly converted to UInteger if the value is large enough to not fit into Integer. But it doesn't work for &b/&o/&h literals. I don't know what the reason for that was.

#print typeof(2147483648)
#print typeof(&h80000000)
#print typeof(&b10000000000000000000000000000000)
#print typeof(&o20000000000)

[stephanbrunker]

Logically, if there's a prefix of zeroes, then the lower Integer should be in any case converted to unsigned by the constructor of the ULngInt/Longint. If you compare:

dim a as longint
a = &h0000000080000001
print a
dim b as integer
b = &h00008001
print b
dim c as short
c = &h0081
print c

Then, the Longint to negative is an (unexpected) exception. And these are quite difficult to find.

[dkl]

Yea, that's something we've talked about before... in FB it works much like C at the moment, i.e. leading zeroes are ignored, but that is not always intuitive.

[dkl]

Made an entry for that here: [feature-requests:#295]

Personally I'm not 100% sold on changing the behaviour yet, but who knows.