I will do that. It might be that the compiler is confused, as the debugger for Windows only
runs in 32-bit mode. But 64 bit values should be allowed in any case in expressions.
If you have xDev then read my article about integer overflow errors.
You have 1024, an integer. A 32bit Integer! You multiply with 1024, another 32bit integer. The result is an integer of 1,048,576, another 32bit Integer.
You multiply that integer with another integer of 1024. BANG! Integer overflow error in your app.
If you use 1099511627776, then that is stored as a 64bit Integer.
[quote=364696:@Markus Winter]If you have xDev then read my article about integer overflow errors.
You have 1024, an integer. You multiply with 1024, another integer. The result is an integer of 1,048,576
You multiply that integer with another integer of 1024. BANG! Integer overflow error.[/quote]
However… he said it was a 64bit app… therefore it should be 64 multiplication
and under 64bit macOS it is… and based on what he said, (running my example) he gets the “correct” result
it seems that the COMPARE may be the issue… not the multiplication itself
You are right, it is not overflow. On my Mac running as 32bit:
[code]dim LongFilePointer as UInt64 = 102410241024*1024 // 32bit: 0
dim x1 as integer = 1024 // 32bit: 1024
dim x2 as integer = 10241024 // 32bit: 1048576
dim x3 as integer = 102410241024 // 32bit: 1073741824
dim x4 as integer = 1024102410241024 // 32bit: 0
Dim n1 As Integer = 3123456789 // 32bit: -1171510507 <- overflow
Dim n2 As UInt32 = 3123456789 // 32bit: 3123456789
Dim n3 As UInt64 = 3123456789 // 32bit: 3123456789
Dim n4 As Int64 = 3123456789 + 8 // 32bit: 3123456797
Dim n5 As Int64 = 2147483640 + 8 // 32bit: -2147483648 <- overflow
Dim n6 As Int64 = 3000 * 1000 * 1000 * 1.2 // 32bit: -1553960755 <- overflow
Dim n7 As Int64 = 3000 * 1000 * 1.2 * 1000 // 32bit: 3600000000
Dim n8 As Variant = 3123456789 // 32bit: 3123456789
[/code]
Why are LongFilePointer and x4 zero on 32bit app Mac? It should overflow, not result in zero.
I tried it in REALstudio 2012R1.2 and Xojo 2013 R3.3 with the same result.
Markus… per my post above… IT DOES OVERFLOW on macOS 32bit, at least with Sierra and Xojo2016r4
what would you expect… it results in a 44bit answer… if you take the lower 32bits… they are all zero
however 102310231023*1023 is also a 44bit answer
1095222947841 or 0xFF005FF001
but results in 6287361 or 0x5FF001 (which is also the lower 32bits)
Missing handling integer overflow- and underflow-exceptions are bugs, but Xojo is not the only programming language that has that bug.
Processors have a carry and a overflow flag built in that can be used to handle these situations.
There are enough examples where missing this kind of errorhandling has caused severe disasters, read the examples in this wiki: https://en.wikipedia.org/wiki/Integer_overflow
Many years ago i mentioned it already to Xojo (then named Real software) but still nothing changed.
This affects all types of integer including the currency type, that has even more flaws (division by zero).
I tested Dave’s MsgBox -approach, and it shows no problems with the original expression in
the comparison in the 64-bit (Windows 10) case, with 64-bit code.
But when running as a 32-bit app, necessary for using the debugger in the Windows case,
the problem arises.
As one is allowed to use 64 bit integers in 32 bit code also, this problem should not arise.
If the assembly-code generated could be viewed (like in Delphi or the former OS/2 VisualAge e.g.),
it would be clear that the code generated for the expression is not automatically adapted for
the correct 64-bit comparison, as obligatory by the uint64 variable in the left side.
@ALBERTO SANTOS
It is quite likely that on a 32 bit system with 32-bit code the same error would be seen,
as the LongFilePointer would be uint64 still.