Something funky about UInt32 comparisons

Just a single data point, but I am a full time developer and in the last 15 years using Xojo, I have never used a UInt-anything.


Nope it’s not rare, we use it alot in protocols. I bet many more protocol implementations exist in xojo.

We had a crash in EasyTCPSocket that may be because of this, i’m not sure but it give a light :bulb:.
How to reproduce perhaps.

It used to be Integer, not it’s int32 since a while. This was changed by Xojo…

I most commonly use UInt64 for bit masking. That gives me 64 booleans I can pack into a single variable.

There are places in the framework this comparison bug can bite. It’s a stretch of course, but URLConnection.ReceivingProgressed uses Int64 for its parameters, which means it was designed to handle very large payloads. First of all, those should be UInt64 parameters because they should never logically be less than zero, so that would double the upper bound. But second of all, trying to determine if bytesReceived is greater than zero in a 32-bit app, with a total that is greater than an Int64 can hold, then the comparison will fail. Like I said, this scenario is WAY out there, so I don’t really expect this to sway any opinions. My point however is that comparing integers is faulty even when using the framework.

And @DerkJ is right, unsigned values are common in protocols and also when dealing with binary data.

I’ve also yet to see any examples of how fixing integer comparisons would negatively impact existing code. To be fair though, that may not happen until after Xojo’s morning meeting, if at all.


sorry, this is not a serious answer.
the tale of the citizen developers has tired us all.


@Geoff_Perlman you already explained why Xojo Inc. does not feel good about changing this compiler behaviour. I hope the following Feature Request may be a solution Xojo is willing to at last try with Xojo Testers: feedback://showreport?report_id=61921

Thank you for listening.

The current behaviour is non intuitive. IMHO, it should have been considered when tackling other non intuitive aspects of the eco-system as renaming APIs (v2).

Also, I do no think the problem is limited to Uint vs Int. What’s about currency vs doubles for ex.
Having to CType so often is cumbersome for these simple cases where the compiler could do a better job. Ctype does not help with speed also.

I must say I was bitten several times with this (apps running specialized serial and net prototocols, accounting, etc.). I am more confident in the behaviour of old Fortran 77 compilers than Xojo in this respect, which is a bit disappointing.


I use Uint all the time when bit masking, handling serial communications, porting Java code…


Just also chiming in to say that I also use Unsigned integers, not only in my code, but also when working with Apple’s API.

Take the NSArray object for instance, it’s count function returns a Unsigned integer.


Can you show one piece of code, that depends on the current behavior?

I rather expect that code usually works and randomly fails unexpectedly if the number is bigger/smaller and the wrong result comes.


Thanks for quoting me in the Feedback case. :blush:

1 Like

Me too.

1 Like

If you think feedback://showreport?report_id=61921 would help, maybe put a few Points onto it?

Thank you :slight_smile:

Looking at: @Sam_Rowlands @GarryPettet @Philippe_Schmid @Giacomo_Bernardi @Thom_McGrath @DerkJ @KarenA @Markus_Winter @Hal_Gumbert @Bill_Gookin (i can only mention a max. of 10 users in a post) :wink:

I added it to my top cases.

I wouldn’t get your hopes up though. One of my top cases has been in Feedback for 12 years and hasn’t been implemented: feedback://showreport?report_id=30


That one may be really tricky as you need to have metadata about all the expressions, e.g. which variable to query on which object and then do the query. I think to find from mouse position the text line is easy, but that metadata to know what variable to query at debug time may be tricky.

I have no doubt that it’s hard but the debugger in Xojo could really use some love. Many other IDEs and development environments offer this feature (as well as cooler things like like code injection, etc).

1 Like

It may show up when you check 64-bit UInt64 field in structure or memoryblock for flags:

// let's say you have some memoryblock
Dim m As New MemoryBlock(16)

// we just fill it with some random value including setting top flag
m.Int64Value(0) = -1

// now let'S say you grab a 64-bit UInt64 flags field from a structure used in a declare

Dim flags As UInt64 = m.UInt64Value(0)
If flags > 0 Then 
  // is at least one flag set?
  // never comes here
  // this happens
End If


if  flags<>0  Then

be more appropriate?

Well, for an UInt64, the compare for > 0 and <> 0 should result in same result.

Wow! Your comment reads as patronizing, dismissive and utterly insulting to citizen developers. Perhaps you want to rephrase it?
For the record, citizen developers have just as much potential as professional developers to create complex and competent code. Citizen developers just don’t earn a living wtith that code (yet for some).


Perhaps, but I’d avoid a comparison that hints that I consider the variable possibly has a numeric value in it. Compare to zero/non-zero or mask and compare to zero/non-zero.

I follow this discipline to assist me when I look at the code next time and can’t remember what it’s for :rofl: