OK, fair enough. It’s not a new type in the sense that it’s not exposed to the user. However, you know as well as I do that we are very careful about not breaking code especially in ways that would be hard to detect. In this case, there’s an easy workaround so it doesn’t seem like it that’s worth subtly breaking existing code.
1 Like
I’m sure most who have bitten by this bug has already progammed in the workaround, and so it remains unchanged until it affects the next person. I think this is another example of Sometimes, no news is bad news
4 Likes
I truly believe you are wrong in this instance. I understand your concern about breaking code, you know I do. But even if there is something that would break - which isn’t known at this time - you’re still defending your product being egregiously wrong. This should be fixed, even if broken code becomes more broken. Anybody who has already worked around the problem will be unaffected, as the workarounds will continue to work. Anybody who hasn’t noticed their code is broken will suddenly find it fixed. They may not notice a difference at all. Regardless, the product becomes better for it. Do you know how much time I’ve spent wrapping zeros in CType(0, UInt64) just to work around this? Literally hours. That’s something I’d have to do anyway because it’s not like I’d get a fix tomorrow. But you’re arguing that’s the way it has to be, because you aren’t confident you can get the fix right. This is a solvable problem, yet you’re accepting mediocrity.
For anybody that doesn’t understand the scope of this problem, I’m serious, turn on the warning. Nearly any code that uses an integer type besides Integer will be flagged. UInt8, UInt16, UInt32, UInt64, Int8, Int16, Int32, Int64, and UInteger. They’ll generate warnings all over the place because constants and literals are always Integer, and therefore generates comparison and assignment issues. Oh and be sure to analyze in both 32-bit and 64-bit mode to test really test, since Integer means something else in each.
The code’s already broken. Unbreaking it should be the goal, even if there is some growing pains… which there shouldn’t be anyway.
10 Likes
I’m not defending it being wrong. I’m saying there’s a cost to fixing it and that cost (breaking other user’s code in ways they wouldn’t immediately notice) is too high. If fixing it would highlight every place in their code where the new behavior is present so the user could then make the necessary changes, that would be fine but it doesn’t work that way.
User code should not require changes. The code would start working correctly. Don’t go off of Aaron’s comments in 2218. Aaron was right that any special treatment of the literal will cause some kind of problem. That’s not the case with the proposed solution. There should be no backwards compatibility problems.
1 Like
Doesn’t closing a case remove its rank, and makes it impossible for people to sign on if they are affected? As a test I tried adding both the duplicate and the original 2008 case to my top 5, and they both still said “Rank: None.” In this thread we’ve seen references to 3 separate cases submitted over the years (2218, 11935, and 40465), and within those cases at least 10 people are participating.
While I agree it may not impact many people, or better, most people aren’t aware of the issue, or if it affects them or not (i.e. unknown bugs.) In this case, it feels like math correctness should be win over backward compatibility—If that’s even a concern, as the fix is supposed to be backward compatible.
But entertain me for a second and let’s assume it isn’t compatible, and explore the position “Few people are impacted”.
If that’s the case, what’s stopping us from making the math correct? If very few are impacted one way (i.e. the way it is; with wrong math), then won’t few be impacted the other way too (fixed with smart type promotion; correct math). If you agree that few are impacted both ways, it might as well be the correct way?
Regardless, if the proposed “Comparison Type Promotion” solution is indeed inherently backward compatible, then there’s nothing to worry about. Sure, that’s for your engineers to determine. But will they get a chance to even entertain the idea with the report being closed, as a duplicate of an older closed report, which was made prior to the discovery of a new solution?
YOU CLOSED IT?! The goal is to just sweep the bug under the rug isn’t it? Jason is right, because all the bugs are closed, they can’t be ranked. Your argument that it must not affect a lot of people because it isn’t ranked doesn’t hold water because you won’t allow it to be ranked.
I was curious what a buddy of mine thought of this situation. He’s a senior engineer at Wayfair, so I kinda feel like he has an idea what he’s talking about, don’t you? Here’s his thoughts on the matter.
Just after the end of the screenshot (couldn’t fit it) he concludes “Idk, stuff like this makes me never want to use them.”
It’s embarrassing when your compiler has a math bug. It’s extremely embarrassing when it exists for 10 years without being fixed. It’s downright insane to refuse to fix it. To plug your ears and pretend it’s not happening. This isn’t a minor a bug.
And for now, I’m going to get my kids to school, then pull my twitter account out of retirement to talk to Aaron. I’m not done with this.
14 Likes
Outstanding!
I was curious what a buddy of mine thought of this situation. He’s a senior engineer at Wayfair
And for now, I’m going to get my kids to school, then pull my twitter account out of retirement to talk to Aaron. I’m not done with this.
1 Like
After talking to Aaron Ballman, the general conclusion is that this behavior is right for a C/C++ style language. But Xojo isn’t a C/C++ style language. He says
For Xojo’s target audience of people who write code but don’t consider themselves professional programmers, this is a problem worth solving.
I think it’s reasonable to tell C or C++ programmers “these are the rules of the language and you have to figure out how to make sense of that, best of luck.” But I think it’s less reasonable to make people who aren’t computer scientists sit down and think about how literals get typed and how that impacts basic comparison operations
Personally, I think the best way forward is for integer and floating-point operations to use an infinite precision type
I think it’s also defensible to say this is not a bug. We designed it to behave this way, after all, so it is an intentional design choice. If I had a time machine and infinite resources, I’d do it differently now.
I still wish we bit the bullet and went with infinite precision types. But at the same time, hardware back then wasn’t really good for that sort of thing and RB had no optimizer.
Take that as you will. You know I truly believe this should be fixed.
7 Likes
That may not needed here.
We just need a bit more logic in the compiler for handling various types.
if both sides are the same type, fine, compare them.
If not, upgrade both sides to a common upper type like int64.
If you compare Int64 with UInt64, add extra checks. e.g.
if ValueUInt64 < ValueSInt64 then
becomes internally:
if (ValueUInt64 <= MaxSInt64) and (CType(ValueUInt64, Int64) < ValueSInt64) then
or other direction:
if ValueUInt64 > ValueSInt64 then
will be internally:
if (ValueUInt64 >= MaxSInt64) or (CType(ValueUInt64, Int64) > ValueSInt64) then
There may be 16 or so combinations to handle special like this, but that is doable.
And of course make some unit tests to verify behavior is right for all cases.
3 Likes
@Juyoun_Park Please don’t get my topic shut down. All the bug reports are closed so there is nowhere else to discuss this.
7 Likes
Please don’t get my topic shut down. All the bug reports are closed so there is nowhere else to discuss this.
Understood, not my intention, I will withdraw.
1 Like
It won’t ‘get’ shut down. Xojo will shut it down to silence CUSTOMERS.
2 Likes
Perhaps the cost is too high to fix it because they don’t have a compiler engineer on staff?
Aaron’s point about not doing it the right way many years ago because of both hardware capabilities and RB not having an optimizing compiler, makes the compromise BACK THEN understandable if unfortunate… but that was BACK THEN.
It hard to imaging how the proposed solution would break any code… but if it did it would be a LOT less likely to than subtle bugs caused by things as they are…
This is a subtle bug that can exist and cause erroneous results, but might never be found… Those are the type of issues that need to be fixed REGARDLESS of the number of reports for the product to be respected and trusted widely IMO.
-Karen
9 Likes
Most forums that are owned by the tool provider operate in this way. This is not unique to Xojo - as you are a FileMaker developer too you will know that they maintain a very strong presence in their forums and frequently close threads down for far less than what Xojo allow on here.
Go onto the official Apple/Microsoft forums and see how quick your topics are closed if you stray from the rules.
Personally I find the continual attacks and sniping to be unconstructive.
6 Likes
Is the following correct?
- Few Devs are affected by this issue = A fix will possibly affect a few Devs only
- Some Devs already use a workaround = A fix won’t affect any of those
- Many Devs have possibly an issue because of false comparissons = A fix will just be a fix for of them
If so, please stop arguing with your customers and fix it. Let’s then verify in an Alpha/Beta if this is really causing code to break… I mean, that’s what Xojo pre-realeases are for, or? 
9 Likes
I think Aaron’s explanation is beautiful.
This will be considered a bug by typical Xojo users. Heck, @Thom_McGrath was a Xojo engineer and he considers it a bug. He is not an outlier.
9 Likes
I’m not sure I agree that this is the target audience. What we had 30 years ago was C and not much memory. Now we have more speed, more memory, and more forgiving languages. You use the best tool for the job at the time. I’m not going to declare, well, I’m a professional programmer therefore I have to write in C.
But what I would do is avoid comparing integers of different lengths in any language, unless it was well documented as to what would happen, and unless I had a very good reason. Even then I might look to see what the compiler generated. Comparing unequal-length integers is like comparing floats: best avoided.
2 Likes
It absolutely is. But for clarity, this means people whose day job is something else. People who use Xojo to assist them with their real job. This is the market Xojo is most interested in.
3 Likes
It’s totally false.
Try with a C/C++ compiler yourself.