I don’t have the expertise to comment one way or another, but considering Aaron worked extensively on REALbasic’s compiler (earlier days of Xojo) and he sits on the C++ WG21 standards committee, I’m inclined to believe him.
6 Likes
You can read Aaron’s words quoted above. I don’t think Thom paraphrased as accurately as he could have.
It was about reasonableness and from a certain kind of programmer’s perspective. Not about what actual compilers do.
I personally think Xojo should fix these types of bugs on principle. I understand Geoff’s arguments and I agree with them for the most part, but I also know that feedback can feel like a fruitless exercise as a customer. I know I’ve run into bugs before only to find out that the bug has been known for a long time and is closed.
I haven’t given up on Xojo yet because I like it quite a lot, but I also know that I have put off projects and intentionally avoided using it for some time now. I used to feel like there is nothing else I would want to use, but now I find myself actively looking at other options for projects. I’m still not sure where I will end up, but I don’t think this kind of tech alienation is unique to Xojo. At least for me it isn’t.
My favorite network vendor seems to be getting worse at customer interaction and responding to needs as they try to do more and more in the network space. I find myself avoiding purchases from them that I would have made without a second thought as I bide time to look at other vendors and hope better options come along. They used to be the company that listened better than the others and they fixed problems and it always felt like progress was being made. Now it feels almost the opposite. It seems that you can just about guarantee that once the initial shine wears off you will end up regretting the purchase. I have completely stopped recommending their products to my customers and I can imagine a time within a year or two where it will be possible to stop purchasing their gear completely. How this affects the company long term, I can’t know since I have no inside info, but I can say that if a competitor does step up soon and the company shrinks considerably they will have heard about the issue for years from their customers and it won’t be a surprise to anyone.
There are other examples of this phenomenon I won’t list, but I think there may be some cultural drift away from craft these days that is just infecting everything. I find it in my own work sometimes and I don’t like it. I’m trying to be more aware of it so I can be better myself, but it’s not easy at times with all the distractions these days.
2 Likes
Back in my VAX/PDP-11 days, a coworker encountered a bug that he just couldn’t figure out. I spent 3 days straight pounding on it and finally got to the point of examining the machine code being generated. It was then that I realized it was a compiler bug that was “optimizing” a local variable out of existence inside a loop. I sent a very clear and detailed bug report to DEC. You know it was never fixed. Or even acknowledged.
This bug reminds me of the issue where the left hand variable type isn’t taken into consideration when determining the result type of an arithmetic operation. It works most of the time, but can lead to some interesting edge cases. I think that one has impacted many more people and has come up time and again in the forum and the response has always been an engineer explaining the way it works and the user adding “.0” to some part of their equation.
In a previous life, I was an VAX/VMS applications programmer working for major NYC bank. Our application had a long standing bug that would bring it down occasionally - usually at the most inopportune time before a Fed deadline. The tech gurus never found it but created a very good work-around. One day, like a blind squirrel finding a nut, I found the bug in a macro that was allocating memory but because of misplaced closing bracket (or some such thing) was not deallocating. My boss refused to entertain the idea of fixing it because everyone knew the work-around and it was 99 percent successful. He was the guy that had to deal with the users and he was comfortable living with the one percent chance the bug would rear it’s ugly head.
1 Like
Yep. Sometimes the potential implications of fixing the bug are scarier than living with it. The longer the bug has been around, the worse it gets.
2 Likes
Still useful to document it, though.
Nobody has shown even one example of how fixing this comparison will have a negative impact on user code. As far as I’m concerned, that’s just FUD to avoid actually putting effort into fixing the bug.
11 Likes
@Thom_McGrath From what engineers have told me, every place in every project that uses any Uint type would have to be audited because assumptions may have been made about this behavior.
1 Like
I don’t understand how making that comparison work correctly could adversely affect ANY software… I HIGHLY doubt any software has been written in Xojo that purposely depended on that behavior… It would simply not make sense to have done that.
And if it was unintentional they have a bug that they just have not found…
Can you or any of your engineers give a real world example of a piece of code purposely written that depends on that behavior and would break if the bug was fixed?
I can not think of any.
-Karen
2 Likes
That’s pretty much what I expected to hear. Better to just document it.
All one would have to do is run into this issue, realize what Xojo was doing and workaround it via logic rather than type casting. Three different engineers all said the same thing: because of decisions made early on in the language, changing this now risks breaking code in ways hard to detect.
This is what I’m asking for. I cannot for the life of me think of any comparison that would be beneficial for it to be wrong. It doesn’t make sense.
If I look at the original code, it’s wrong. I may not notice it’s wrong, but it’s wrong. The fix would improve that code.
I I change the original code to
Var Value As UInt32 = 4294967295
If Value <= CType(0, UInt32) Then
MessageBox("Value is less than 0")
Else
MessageBox("Value is greater than 0")
End If
I have worked around the bug, and the fix will not negatively impact my code.
If I simply reversed the logic:
Var Value As UInt32 = 4294967295
If Value > 0 Then
MessageBox("Value is less than or equal to 0")
Else
MessageBox("Value is greater than 0")
End If
… this doesn’t even make sense and my code deserves to break, especially since it STILL doesn’t work.
Give me just one example of code that would be negatively impact by WORKING comparisons. I’m only human, so maybe there’s something I’m not considering, but I can’t for the life of me think of a way this logic can be beneficial.
Prove those claims, and I’ll back off. Otherwise, I will not shut up about it. And quite frankly, defending this behavior is a really stupid hill to die on.
7 Likes
The standard solution to that is compiler flags. This satisfies both needs…
1 Like
We have talked about that. If this impacts enough people to go through all of that, that would be the likely solution. But that’s not a minor thing because you’d want new projects to default to the new behavior.
All I can do is shake my head… it’s like saying if I try adding 17956246 + 286491 and I get 25 … but it only happens if you add exactly those two numbers, it would not be worth fixing… and this is NOT that specific
These are the type of quality items that Xojo needs to be concerned with to have a chance to be taken more seriously IMO…
And that is exactly the type of bug that many “Citizen Developers” would not have a prayer of finding or understanding if they did find it. For the first several years i was using RB that would have been me.
-Karen
4 Likes
This only impacts users that use UInt values. That’s rare amongst Xojo users especially citizen developers.
1 Like
All I can say is that I use them often for things that can not be less than 0.
-karen
3 Likes
I guess we never got the memo that we weren’t intended to actually use them. And though I can’t find it, I swear API 2 uses UInteger.
2 Likes
I’m sure you do but the average user does not.
Do you have any data for this? I wonder what this mysterious “average user” is based on or if it’s made up to support what is convenient?
1 Like