Unsigned datatypes

[Kr00l]

Is your feature request related to a problem? Please describe.
VB6/VBA has no unsigned datatypes, except the 'Byte' datatype.

Describe the solution you'd like
Unsigned datatype for 'Integer', 'Long' and 'LongLong'.
And a signed version of 'Byte'.

Additional context
Naming proposals:
UInteger (unsigned integer)
ULong (unsigned long)
ULongLong (unsigned long long)
SByte (signed byte)

Edit: (and corresponding conversion functions)
CUInteger()
CULong()
CULongLong()
CSByte()

[bclothier]

Like!

For consideration, though, we may need to also support the equivalent of C#'s unchecked to help guard against overflow.

Furthermore, for Automation compatibility, this may need to be flagged if it is exposed. I don't think it should be prevented from doing so but this can cause problem in the clients that expect the COM server to be Automation-compatible.

[Kr00l]

'ULongPtr' would also makes sense to enable easier pointer arithmetic. I know that you will have this in mind, just for the records.

[wqweto]

Another option is to keep LongPtr signed (for automation compatibility) but remove overflow checks on add/sub in codegen so that DestPtr = StrPtr + Offset and Diff = DestPtr - SrcPtr never fail the way they do now with Longs in 32-bit processes around 2GB boundary.

I'm really baffled that this is not already implemented in VBA 7 (LongPtr not being available in VB6) but Microsoft missed opportunity fixing this when they got 32-bit MS Office LARGEADDRESSAWARE compatible some years ago so now LongPtr pointers in VBA still remain actually LAA non-compatible in reality.

Btw, do ULongPtr and other unsigned types overflow on CULng(0) - CULng(1) for instance? Are they going to have type suffix symbols for numeric literals e.g. 123U& for ULong

[WaynePhillipsEA]

@wqweto Yes, you're quite right there. I suspect the proposed change would not affect the vast majority of code adversely, but I'd prefer to see the overflow checks on LongPtr to be removed only via a project flag (or perhaps automatically applied when the current LAA flag is set in the project settings), purely due to maintaining full backwards compatibility with VBA.

With regards to unsigned type overflows, yes we'll be following the existing (unsigned) Byte behaviour. And also yes, we'll be adding the U suffix for the datatype characters. Thanks!

[wqweto]

Btw, in VBA x64 LongLongs do not raise error on some overflows during arithmetic operations when being wrapped in Variants

? TypeName(CVar(&H4000000000000000^))
LongLong
? CVar(&H4000000000000000^) 
 4611686018427387904 
? TypeName(CVar(&H4000000000000000^) * 2)
LongLong
? CVar(&H4000000000000000^) * 2
-9223372036854775808 
? Hex$(CVar(&H4000000000000000^) * 2)
8000000000000000

Notice how the overflow spills into the sign bit which is probably a bug, a useful one too :-))

[WaynePhillipsEA]

Yes, looks the same in tB, which would be expected with it using the same OS variant functions (VarMul etc)