Create a new desktop app with this in Window.Opening event:
Dim value As UInt32 = val("-1")
MsgBox(Str(value))
Build a mac universal app on Xojo 2024r3.1. When you run the app on an Intel Mac it shows “4294967295”, but when run it on an ARM MacMini it shows “0”.
Is this a bug in Xojo, or are you just not meant to set a “U” variable to -1? Thanks
The result should be consistent across targets.
My gut feeling is that Intel (4294967295) is correct and Apple Silicon (0) is incorrect.
I recommend you log a bug.
Well, if you remove ‘val’ from your code, then there is no difference between Intel and ARM.
Something wrong with the use of ‘val’ in this case.
Yes, you’re definitely not meant to assign an out-of-range value to a variable; the results are unpredictable. Looks like you may be exposing a difference in how this situation is handled on the two different architectures.
But is it a bug? Should unpredictable behavior be … predictable? Consistent? I’d argue no, but I might also argue that value as UInt32 = -1 should throw an OutOfBoundsException.
From the Xojo documentation at: Integer — Xojo documentation
If you assign a value that is larger (or smaller) than what the specific Integer type can hold, then the value will “overflow”. This means the value will wrap around to the corresponding largest or smallest value and continue from there.
The value should have been 4294967295.
This code shows different results using Intel or ARM on mac:
Dim value As UInt32 = val("-1")
MsgBox(Str(value))
do you expect this code to work the same as above or different?
Dim value As UInt32 = -1
MsgBox(Str(value))
Val takes a String and returns a Double. You’re then converting that to an Integer and assigned to an Unsigned Integer. That conversion path may be leading to differences for each platform.
Shouldn’t. Is it confirmed on latest versions? If so, serious bug.
Indeed, it would be. I’m only pointing out places that could have a bug.
@Rick_Araujo - Thanks for tracking this down. Did you create an issue for it?
Mark is the OP. Maybe he didn’t. I certainly not.
I looked and didn’t see one.
I’m not sure I 100% understand/know how to best explain the issue, or I’d post it myself.
In few minutes I’ll report it then, busy now.
Here’s what I see on Intel (macOS).
Even weirder!!!
uFromDouble is 12
Edit: oops! that was testing with an unreleased beta.
Testing with 2024R3.1, I see this:
Something strange is afoot!
Thanks @Rick_Araujo and everyones reply. Here’s issue report if you want to add your findings. Thanks
I reported this as a beta bug here: https://tracker.xojo.com/xojoinc/xojo/-/issues/77975 feel free to add your experiences there, or create a new bug as needed. I feel like we may be seeing two bugs?
Very, very math inconsistent. Serious bug.
UInteger and its variants are meant to be unsigned integers, so a negative value should probably be undefined.
If you think in bytes, it isn’t surprising that -1 gives you the maximum positive value for the unsigned integer size on the Mac - this is traditional behaviour.
0 isn’t necessarily wrong since a negative value shouldn’t exist in this type.
I agree they should be consistent, but it shouldn’t matter because they’re not meant to be used this way.
I agree. If a datatype has a constraint, then some check logic should be in place to ensure the assignment does not cause an overflow or error.
This problem is not unlike checking for a divide-by-zero condition.
If factor2.Equals(0.0, 1) Then
// avoid divide-by-zero error and just assign zero
calculated = 0.0
Else
// safe to calculate
calculated = factor1 / factor2
End If
These are not new problems.
#68266 - raise exceptions when numeric operations overflow and underflow
#68267 - new pragma to ignore overflow underflow
#68144 - Raise an exception when dividing by 0
#68142 - Divide by 0 behavior on Windows/Linux does not match docs