search

twinbasic / lang-design

Language Design for twinBASIC
MIT License
11 stars 1 forks source link

Unsigned datatypes #9

Open Kr00l opened 3 years ago

Kr00l commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

wqweto commented 3 years ago

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 commented 3 years ago

@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 commented 2 years ago

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 commented 2 years ago

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