Inconsistent length types

General
1

Anyone bothered by this?

FolderItem.length is a UInt64
MemoryBlock.size is an Integer
BinaryStream.BytePosition is a UInt64
BinaryStream.Length is a UInt64
BinaryStream.Read(ByteCount as Integer...)

It means code like this:

var bs as BinaryStream 
[...]
var data as String = bs.read(bs.length)

throws as complier warning. The compiler warning is incorrect, too, as it says

Converting from UInt64 to Integer causes the sign information to be lost, which can lead to unexpected results

The conversion is actually sign-preserving, but it might cause an overflow.

Reported as https://tracker.xojo.com/xojoinc/xojo/-/issues/77445

1 Like
2

IIRC, the reason MemoryBlock uses Integer is to match the bitness of the OS that you’re running on, so you can’t create a 16TB memoryblock on a 32-bit OS.

I agree that it’s he length parameter of the read method should be a uint64 though.

1 Like
3

I believe there was a specific reason for that @William_Yu has explained in an issue about the binarystream .read(…) an .length parts

4

I’ve always felt like we need SignedInteger and UnsignedInteger in the language for these situations. After all, it IS a strongly typed language. :wink:

5

That already exists. it’s called UInteger.

3 Likes
6

That’s what I get for not consulting the documentation before shooting my mouth off. :wink: Thanks for the tip!

7

as workaround you could use ctype

Xojo should provide an compiler option

UseIntegerAs64Bit
UseIntegerAs32Bit

and BinaryStream Length or BytePosition are just Integer