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.
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.
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.
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.
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 !
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 .
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.
@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.
The type of a numeric literal or constant that is a whole number is the same integer 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.
Therefore to correctly compare them, use CType to cast the literal to a UInteger.
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.
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.
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).
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!”
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.
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