# Something funky about UInt32 comparisons **URL:** \ **Category:** General\ **Created:** [September 27, 2020, 7:20pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447 "2020-09-27T19:20:07Z")\ **Posts on this page:** 18\ **Page:** 9
**Author:** ![Thom\_McGrath](https://forum.xojo.com/user_avatar/forum.xojo.com/thom_mcgrath/32/192_2.png) [@Thom\_McGrath](https://forum.xojo.com/u/Thom_McGrath)\ **Post date:** [October 1, 2020, 8:41pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/164 "2020-10-01T20:41:10Z")
> [@Geoff\_Perlman](#): > > This occurs when comparing a Uint to constant or literal that has a value that is outside of the bounds of a signed integer. This is wrong. This happens when comparing an unsigned integer that is outside the range of a signed integer to any other integer, such as a constant or literal. That’s why my original code fails when compared to 0. 0 is not outside the range of any integer. > [@Geoff\_Perlman](#): > > This behavior is not a bug. It’s by design. Just because it’s by design doesn’t mean it isn’t a bug. It’s absolutely a bug because it’s a bad design. You can’t convert a UInt32 to an Int32 without data loss, but that’s exactly what Xojo does. Just because that was the chosen behavior, doesn’t mean it’s the right behavior. > [@Geoff\_Perlman](#): > > We have chosen not to change the behavior because there’s a simple solution for those that ever run into this which now has been documented. Tell that to my 847 compiler warnings. Try it in the IDE sometime. Tell me how that goes for you and how much desire you have to workaround this bug. Maybe weigh the collective disappointment of your users when they experience the crushing realization of just how big an issue this is against your cost of fixing it. The bang for the buck is that your developer tool won’t make a stupid comparison. There should be no hesitation, yet here we are. ---
**Author:** ![TimStreater](https://forum.xojo.com/user_avatar/forum.xojo.com/timstreater/32/586_2.png) [@TimStreater](https://forum.xojo.com/u/TimStreater)\ **Post date:** [October 1, 2020, 8:54pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/165 "2020-10-01T20:54:00Z")
> [@Randy\_Young](#): > > And I disagree with Tim Streater, backward compatibility is not a justification for leaving it and documenting the bug is not an acceptable solution. Defending it by saying that SQLite has rules they won’t change is not providing a WRONG answer. You didn’t read what I wrote: I was merely pointing out that not changing things in order to preserve backwards compatibility is not so unusual. Don’t assume that means I am defending the staus quo. And I still want to know why people might be comparing the magnitude of unsigned integers that they are using to store bits in, with anything at all. Equal or not to zero is one thing; seeing if a bit field is greater than another or with a signed number makes no sense. ---
**Author:** ![Gilles\_Plante](https://forum.xojo.com/user_avatar/forum.xojo.com/gilles_plante/32/667_2.png) [@Gilles\_Plante](https://forum.xojo.com/u/Gilles_Plante)\ **Post date:** [October 1, 2020, 8:58pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/166 "2020-10-01T20:58:57Z")
I have used a lot of languages and compilers. Some of development tools editors like to pamper you by make it so to correct the developers’ errors. How nice it is . . . and one day that impacts you because you can’t do what you wish to do \_ nothing’s specific come to my mind. I hate it when something is taken care of by the development tool because I don’t want to recall all of those, for example operators precedence. I make it clear by using parentheses, this way I set the precedence and everybody can see it. Back to the post subject, I think is preferable to set myself the type of a value from a literal. In C it’s as easy as `if (abc != 10L) . . .` The L suffix tells that 10 is a long value. Very neat. I would love Xojo uses the C suffix instead of CType ! ---
**Author:** ![Geoff\_Perlman](https://forum.xojo.com/user_avatar/forum.xojo.com/geoff_perlman/32/48_2.png) [@Geoff\_Perlman](https://forum.xojo.com/u/Geoff_Perlman)\ **Post date:** [October 1, 2020, 9:19pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/167 "2020-10-01T21:19:19Z")
> [@Thom\_McGrath](#): > > This is wrong. This happens when comparing an unsigned integer that is outside the range of a signed integer to any other integer, such as a constant or literal. That’s why my original code fails when compared to 0. 0 is not outside the range of any integer. I stand corrected but this only makes the impact surface even tinier. And why are you getting compiler warnings over this? ---
**Author:** ![anon20074439](https://forum.xojo.com/letter_avatar_proxy/v4/letter/a/ac8455/32.png) [@anon20074439](https://forum.xojo.com/u/anon20074439)\ **Post date:** [October 1, 2020, 9:21pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/168 "2020-10-01T21:21:43Z")
> [@Gilles\_Plante](#): > > The L suffix tells that 10 is a long value. Very neat. I would love Xojo uses the C suffix instead of CType ! I’m sure I could implement that in a few minutes using my reformat code script, it would however convert the 10L to Ctype(10, Int32) when you moved off the line, not quite as neat but as quick to type. If you want it added PM me a link to a reference and I’ll see what I can do tomorrow . ---
**Author:** ![Thom\_McGrath](https://forum.xojo.com/user_avatar/forum.xojo.com/thom_mcgrath/32/192_2.png) [@Thom\_McGrath](https://forum.xojo.com/u/Thom_McGrath)\ **Post date:** [October 1, 2020, 9:32pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/169 "2020-10-01T21:32:54Z")
> [@Geoff\_Perlman](#): > > I stand corrected but this only makes the impact surface even tinier. And why are you getting compiler warnings over this? No. No it doesn’t. It makes it far greater. All you have to do is compare an unsigned integer to a signed integer such as a literal or constant. The compiler warning comes from the “loss of sign warning” in analysis warnings. Because the compiler demotes the UInt to Int, the sign is lost, and the warning is generated. ---
**Author:** ![LangueR](https://forum.xojo.com/letter_avatar_proxy/v4/letter/l/9d8465/32.png) [@LangueR](https://forum.xojo.com/u/LangueR)\ **Post date:** [October 1, 2020, 9:40pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/170 "2020-10-01T21:40:06Z")
> [@Thom\_McGrath](#): > > No. No it doesn’t. It makes it far greater. @Thom_McGrath - In the alternate reality of the the Feedback System it makes it tiny. The system is probably using that bug (sorry “feature”) to make the threshold comparisons. ---
**Author:** ![AlbertoD](https://forum.xojo.com/letter_avatar_proxy/v4/letter/a/dbc845/32.png) [@AlbertoD](https://forum.xojo.com/u/AlbertoD)\ **Post date:** [October 1, 2020, 9:55pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/171 "2020-10-01T21:55:31Z")
The docs were updated yesterday: ### Comparing a UInteger to a Literal or Constant The type of a numeric literal or constant that is a whole number is the same [integer](https://documentation.xojo.com/api/data_types/integer.html) type as the architecture of the platform for which you are building. That means that if you are building for 64 bit, literals and constants will be 64 bit (signed) [integers](https://documentation.xojo.com/api/data_types/integer.html). Therefore to correctly compare them, use [CType](https://documentation.xojo.com/api/data_types/additional_types/ctype.html) to cast the literal to a UInteger. ---
**Author:** ![Thom\_McGrath](https://forum.xojo.com/user_avatar/forum.xojo.com/thom_mcgrath/32/192_2.png) [@Thom\_McGrath](https://forum.xojo.com/u/Thom_McGrath)\ **Post date:** [October 1, 2020, 10:03pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/172 "2020-10-01T22:03:07Z")
> [@AlbertoD](#): > > The docs were updated yesterday That’s all well and good for now. The next step is to fix the comparison. ---
**Author:** ![KarenA](https://forum.xojo.com/letter_avatar_proxy/v4/letter/k/c89c15/32.png) [@KarenA](https://forum.xojo.com/u/KarenA)\ **Post date:** [October 1, 2020, 10:06pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/173 "2020-10-01T22:06:38Z")
> [@Thom\_McGrath](#): > > That’s all well and good for now. The next step is to fix the comparison. While that is 100% what SHOULD happen, it sounds like it will not… I truly don’t understand how Geoff does not understand how much of a black eye that is for the production. - Karen ---
**Author:** ![Geoff\_Perlman](https://forum.xojo.com/user_avatar/forum.xojo.com/geoff_perlman/32/48_2.png) [@Geoff\_Perlman](https://forum.xojo.com/u/Geoff_Perlman)\ **Post date:** [October 2, 2020, 12:20pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/174 "2020-10-02T12:20:14Z")
This has been the behavior for more than 10 years. If this behavior was such a huge problem, we would know it by now. The reality is that it’s not. It was by design because literals have always been signed integers. As I have said, we could make the comparison automatic but everything has a cost and the impact surface of the suggested change in behavior is not worth the cost. ---
**Author:** ![Mike\_D](https://forum.xojo.com/user_avatar/forum.xojo.com/mike_d/32/266_2.png) [@Mike\_D](https://forum.xojo.com/u/Mike_D)\ **Post date:** [October 2, 2020, 1:50pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/175 "2020-10-02T13:50:32Z")
> [@Geoff\_Perlman](#): > > If this behavior was such a huge problem, we would know it by now. The reality is that it’s not. That conclusion is not justified as it relies on data tainted by survivorship bias. There’s no way for Xojo to know the # of people who abandoned the product (or who test it but give up before purchasing) due to these sorts of long-standing unfixed issues. ---
**Author:** ![KarenA](https://forum.xojo.com/letter_avatar_proxy/v4/letter/k/c89c15/32.png) [@KarenA](https://forum.xojo.com/u/KarenA)\ **Post date:** [October 2, 2020, 2:26pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/176 "2020-10-02T14:26:07Z")
> [@Mike\_D](#): > > There’s no way for Xojo to know the # of people who abandoned the product (or who test it but give up before purchasing) due to these sorts of long-standing unfixed issues. Never mind having the bug but never realizing it because that branch was not exercised during testing. -Karen ---
**Author:** ![Geoff\_Perlman](https://forum.xojo.com/user_avatar/forum.xojo.com/geoff_perlman/32/48_2.png) [@Geoff\_Perlman](https://forum.xojo.com/u/Geoff_Perlman)\ **Post date:** [October 2, 2020, 2:26pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/177 "2020-10-02T14:26:41Z")
> [@Mike\_D](#): > > There’s no way for Xojo to know the # of people who abandoned the product (or who test it but give up before purchasing) due to these sorts of long-standing unfixed issues. That could be applied to every aspect of Xojo from the marketing messages, to the graphics of our website, the download process, the icons we use in the Library, the documentation, the forum, the details of specific features and every single bug. Unless you want to be paralyzed by analysis, you have to make due with the information you have. Unsigned integers are a specialty data type. They have their use for sure but they are rare. In 22 years of looking at user’s code, they almost never appear. I’m sure they appear often for people on this thread but that’s like walking into an ice cream shop and asking who likes ice cream. On top of that, you need to be comparing a constant or literal integer to an unsigned integer having used a value that is out of bounds makes it even more rare. And now that we have documented the proper way to make sure comparisons, you’d have to have somehow not noticed that as well. As for “long-standing unfixed issues”, the age of a bug is not relevant. Only the impact surface matters. From time to time we survey those who tried Xojo but had not yet purchased. It’s extremely rare to hear that they have decided against it because it’s got too many bugs. Far more common are that it’s missing some feature or they didn’t realize how much programming they’d actually have to do (they thought it was even more low code than it is). ---
**Author:** ![Thom\_McGrath](https://forum.xojo.com/user_avatar/forum.xojo.com/thom_mcgrath/32/192_2.png) [@Thom\_McGrath](https://forum.xojo.com/u/Thom_McGrath)\ **Post date:** [October 2, 2020, 3:06pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/179 "2020-10-02T15:06:15Z")
> [@Geoff\_Perlman](#): > > And now that we have documented the proper way to make sure comparisons, you’d have to have somehow not noticed that as well. Um… how do you expect it to be noticed? I have no idea where the new documentation is. Every integer type? Every comparison operator? Some special page? How am I expected to stumble upon the tip? Why would I go looking for it when writing a simple `If Var > Value` statement? There’s literally no reason to suspect the line to be a problem. It’s just there to say “look, we documented it, so our hands are clean!” ---
**Author:** ![Philippe\_Schmid](https://forum.xojo.com/letter_avatar_proxy/v4/letter/p/b19c9b/32.png) [@Philippe\_Schmid](https://forum.xojo.com/u/Philippe_Schmid)\ **Post date:** [October 2, 2020, 3:08pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/180 "2020-10-02T15:08:17Z")
I think the discussion should not be around bug or not (I have an opinion on this), but wether the current implementation makes sense short term or long-term. I really do think the current situation is abnormal and do not know other dev. env. having the same problem but I might be wrong. Also, not being able to set the type of numeric constants does not help. CType is at best cumbersome, almost ridiculous. Would a bit more resources allocated in correcting old design decision and other bugs corrections also help consolidate Xojo reputation long term ? Yes, I strongly think so. IMHO, more than API 2. Reputation problems will not come first and foremost with new users or people interested in trying Xojo. Often these kind of compiler problems are detected when already invested in projects. So the real problem is losing professionals with a lot of expertise because they lose confidence in the tool / eco-system. This is the real challenge. ---
**Author:** ![Dana\_Brown](https://forum.xojo.com/user_avatar/forum.xojo.com/dana_brown/32/15210_2.png) [@Dana\_Brown](https://forum.xojo.com/u/Dana_Brown)\ **Post date:** [October 2, 2020, 3:10pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/181 "2020-10-02T15:10:31Z")
---
**Author:** ![Dana\_Brown](https://forum.xojo.com/user_avatar/forum.xojo.com/dana_brown/32/15210_2.png) [@Dana\_Brown](https://forum.xojo.com/u/Dana_Brown)\ **Post date:** [October 2, 2020, 3:11pm UTC](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447/182 "2020-10-02T15:11:52Z")
As Geoff said multiple times, this behavior is 10+ years old and by design. It looks like there is now a feature request for this. If it is important to you please see the case: [https://xojo.com/issue/61921](https://xojo.com/issue/61921) [Previous page](https://forum.xojo.com/t/something-funky-about-uint32-comparisons/57447.md?page=8)