12-29-2023, 02:27 PM
For folks that haven't bothered to read the various other topics on the forums here (especially one multiple pages deep), CONST is currently bugged. At the moment, it's suffering from a glitch that was made obvious via the latest set of fixes to CONST. (Fix one thing, break two more -- isn't that one of the core rules of programming? LOL!)
At the moment, there are instances where CONST will *negate* the resulting value for us. Const foo = 1 will assign a value of -1 to foo... This is a 100% glitch and is being patched even now by the dev team. (It's not something so obvious as to work with 1, but the previous was just an illustration. Where you can find the glitch is with CONST foo = &HFFFF which returns a value of - &HFFF.)
BUT, while working on this patch, we also noticed that there was a secondary issue with CONST which needed fixing. In the past, CONST has always returned UNSIGNED values to us with &H, &O, &B numbers. This is 100% on me, as I'd just always considered hex values and such to be unsigned.
THIS IS WRONG!!
Our guiding goal has always been QB45 compatibility, and I'd love for someone to show me where QB45 had an unsigned variable type...
In QB45, &HFFFF returns a value of -1, as it represents a SIGNED INTEGER value in hex.
In QB45, &HFFFFFFFF also returns a value of -1, as it represents an UNSIGNED LONG value in hex.
Due to Steve not realizing this, QB64 has been returning SIGNED values for those numbers in the past. &HFFFF would return 65635 and &HFFFFFFFF would return 4billion-something.
Where this makes a drastic change would be if someone ever did something such as:
CONST foo = &HFFFF + &HFFFFFFFF
In QB45, the answer to that would be -- as shocking as it seems to my poor brain -- MINUS TWO.
&HFFFF = -1 (as signed integer)
&HFFFFFFFF = -1 (as signed long)
-1 + -1 = -2 (add those together and get -2)
^That's just mind boggling to me personally, but it is what it is. For our goal of maintaining backward's compatibility, CONST needs to have this same behavior. Used outside of CONST, QB64 already does this type of bizarre type-casting. It's just that I never accounted for this behavior in CONST itself, and now that oversight is going to be fixed soon.
And this fix may affect your code.
If you relied on the same incorrect understanding that I did -- that unsuffixed values default to unsigned values, then you're going to be bit by these changes.
CONST foo = &HFF000000 + &HFFFF is no longer going to add up to be &HFF00FFFF. Instead, it's going to end up being &HFEFFFFFF. (It'll subtract that signed one instead of adding the unsigned 65535 for that integer.)
The fix here is rather simple: You need to manually assign the correct type to those hex values.
CONST foo = &HFF000000~& + &HFFFF~& <-- This makes both values unsigned longs, rather than default QB45 types of signed long and signed integer.
Be aware of this upcoming change and look over any existing code which you may be using. This might affect how QB64PE compiles and runs for you. We've had glitched behavior here with CONST giving signed values for &H, &O, and &B values, and that's being fixed. If your code *worked* under that glitch, it may *not* work now that the glitch is being fixed.
One particular place folks might want to double check their code is with color values.
CONST Blue = &HFF0000FF used to return unsigned long values to us. In the near future, once the patch is approved and added into the language, &HFF0000FF will instead give us a SIGNED long value.
As I mentioned above, the fix for this is to make certain you tell QB64 that you wanted it to be unsigned to begin with:
CONST Blue = &HFF0000FF~&
Unless you specify the type yourself, QB64 is going to try and follow the same logic that QB45 used in determining what variable type to return a value back to you. In the past, it failed at that determination and always returned unsigned values. That's being fixed, and if you relied on that glitch, then you'll need to go back and correct your code to keep up with the fix.
At the moment, there are instances where CONST will *negate* the resulting value for us. Const foo = 1 will assign a value of -1 to foo... This is a 100% glitch and is being patched even now by the dev team. (It's not something so obvious as to work with 1, but the previous was just an illustration. Where you can find the glitch is with CONST foo = &HFFFF which returns a value of - &HFFF.)
BUT, while working on this patch, we also noticed that there was a secondary issue with CONST which needed fixing. In the past, CONST has always returned UNSIGNED values to us with &H, &O, &B numbers. This is 100% on me, as I'd just always considered hex values and such to be unsigned.
THIS IS WRONG!!
Our guiding goal has always been QB45 compatibility, and I'd love for someone to show me where QB45 had an unsigned variable type...
In QB45, &HFFFF returns a value of -1, as it represents a SIGNED INTEGER value in hex.
In QB45, &HFFFFFFFF also returns a value of -1, as it represents an UNSIGNED LONG value in hex.
Due to Steve not realizing this, QB64 has been returning SIGNED values for those numbers in the past. &HFFFF would return 65635 and &HFFFFFFFF would return 4billion-something.
Where this makes a drastic change would be if someone ever did something such as:
CONST foo = &HFFFF + &HFFFFFFFF
In QB45, the answer to that would be -- as shocking as it seems to my poor brain -- MINUS TWO.
&HFFFF = -1 (as signed integer)
&HFFFFFFFF = -1 (as signed long)
-1 + -1 = -2 (add those together and get -2)
^That's just mind boggling to me personally, but it is what it is. For our goal of maintaining backward's compatibility, CONST needs to have this same behavior. Used outside of CONST, QB64 already does this type of bizarre type-casting. It's just that I never accounted for this behavior in CONST itself, and now that oversight is going to be fixed soon.
And this fix may affect your code.
If you relied on the same incorrect understanding that I did -- that unsuffixed values default to unsigned values, then you're going to be bit by these changes.
CONST foo = &HFF000000 + &HFFFF is no longer going to add up to be &HFF00FFFF. Instead, it's going to end up being &HFEFFFFFF. (It'll subtract that signed one instead of adding the unsigned 65535 for that integer.)
The fix here is rather simple: You need to manually assign the correct type to those hex values.
CONST foo = &HFF000000~& + &HFFFF~& <-- This makes both values unsigned longs, rather than default QB45 types of signed long and signed integer.
Be aware of this upcoming change and look over any existing code which you may be using. This might affect how QB64PE compiles and runs for you. We've had glitched behavior here with CONST giving signed values for &H, &O, and &B values, and that's being fixed. If your code *worked* under that glitch, it may *not* work now that the glitch is being fixed.
One particular place folks might want to double check their code is with color values.
CONST Blue = &HFF0000FF used to return unsigned long values to us. In the near future, once the patch is approved and added into the language, &HFF0000FF will instead give us a SIGNED long value.
As I mentioned above, the fix for this is to make certain you tell QB64 that you wanted it to be unsigned to begin with:
CONST Blue = &HFF0000FF~&
Unless you specify the type yourself, QB64 is going to try and follow the same logic that QB45 used in determining what variable type to return a value back to you. In the past, it failed at that determination and always returned unsigned values. That's being fixed, and if you relied on that glitch, then you'll need to go back and correct your code to keep up with the fix.
![[Image: image.png]](https://i.ibb.co/PDR19DB/image.png)
![[Image: Const-Problem2023-12-29.jpg]](https://i.ibb.co/QJn4NzP/Const-Problem2023-12-29.jpg)
