macOS Catalina: 32-bit is Dead!

Reassuring to know that Xojo will continue to only support 32-bit arrays.

32bit arrays?

the question is how long we keep a checkbox for building 32-bit apps.
Not sure how many people still have not ported to 64-bit, e.g. due to use of old APIs or old libraries.

[quote=440557:@Christian Schmitz]32bit arrays?

the question is how long we keep a checkbox for building 32-bit apps.
Not sure how many people still have not ported to 64-bit, e.g. due to use of old APIs or old libraries.[/quote]
They can keep building with older releases.

I think Adrian read the blog post macOS Catalina: 32-bit is Dead! – Xojo Programming Blog
From it:

I hope that includes building from Windows/Linux, but I know that LLVM is not 100% ready.

Hi Christian,

Sorry, the sarcasm at my end may have been misplaced. Are you saying that newer versions of RB/Xojo do now allow for 64-bit sized arrays? I was still basing this on the online notes:

Arrays are limited to 32-bit size in 64-bit apps.

[quote=440561:@Adrian Platts]Hi Christian,

Sorry, the sarcasm at my end may have been misplaced. Are you saying that newer versions of RB/Xojo do now allow for 64-bit sized arrays? I was still basing this on the online notes:

Arrays are limited to 32-bit size in 64-bit apps.[/quote]
Could you point me to where you found that?

It may be that arrays are limited to 32-bit for the index, so only 2 or 4 billion entries. That should not be a problem for you.

The data type is not limited.

https://documentation.xojo.com/topics/application_structure/coding_guidelines_for_64-bit_apps.html
Other 64-bit Information

[quote=440565:@Alberto De Poo]Coding guidelines for 64-bit apps — Xojo documentation
Other 64-bit Information[/quote]
Thank you. I’ve created a case for adding that note to the relevant Language Reference pages.
<https://xojo.com/issue/55969>

It’s worth noting that Arrays are not actually limited to 32-bit in size, it is the array indexes that are limited to 32-bit. I would argue that if you have a need to for an array that has two billion items in it, you should probably be using a MemoryBlock anyway.

there’s a funky edge case right around the max of a signed int32

Const i As Integer = &h7FFFFFFF
Dim i1 As Integer = i
Dim d(i) As UInt8
d(i) = 1

Break

wont work
but changing the const to &h7FFFFFFE (1 less) does

<https://xojo.com/issue/55970>

[quote=440564:@Christian Schmitz]It may be that arrays are limited to 32-bit for the index, so only 2 or 4 billion entries. That should not be a problem for you.

The data type is not limited.[/quote]

I think I’m running into this same issue again, and it appears to me that its not the index that’s 32-bit limited. I’m compiling on MacOS for linux 64-bit using 2019 release 1.1 with the executable running on an Ubuntu machine with 32GB of RAM. If I do a RAM check and then run the simple loop below with a byte datatype which uses in theory 585MB of memory for the array, all works fine:

[code]dim gnm(12,45000000) as byte
dim x,y as integer

for x=0 to 12
print str(x)
for y=0 to 45000000
gnm(x,y)=1
next
next

print “Done”[/code]

~$ free -g
total used free shared buff/cache available
Mem: 31 0 29 0 1 30
Swap: 0 0 0

~$ ./test1
0
1
2
3
4
5
6
7
8
9
10
11
12
Done

But if I change the datatype to double pushing the amount of memory needed to 4.7GB then I get a very different result:

[code]dim gnm(12,45000000) as double
dim x,y as integer

for x=0 to 12
print str(x)
for y=0 to 45000000
gnm(x,y)=1000
next
next

print “Done”[/code]

~$ free -g
total used free shared buff/cache available
Mem: 31 0 29 0 1 30
Swap: 0 0 0

~$ ./test1
0
Segmentation fault (core dumped)

It looks like the inner look gets just past 3.7million when it seg faults. I’ve repeated this on a CentOS machine with 300GB of RAM and had the same result. Any clues to what may be going wrong?