Upcoming changes to CONST may affect your code

[bplus]

It was broken long before when using hex and comparing a Point color to it, so I don't expect it to effect much. l already started using ~& or RGB32() colors to fix graphics I was attempting.

To me this is a long awaited fix, I doubt it will make anything incompatible?

[mdijkens]

It was broken long before when using hex and comparing a Point color to it, so I don't expect it to effect much. l already started using ~& or RGB32() colors to fix graphics I was attempting.

To me this is a long awaited fix, I doubt it will make anything incompatible?

Well, your Sudoku triggered it with me; all colors were black 
With my own code, I only had a few of these and only with colors like Const CLR_RED = &hFFFF0000
now replaced all with  Const CLR_RED = &hFFFF0000~& or Const CLR_RED = _RGB32(255,0,0)

[SMcNeill]

Honestly, this issue may not be as bad a glitch as I was first thinking.   It seems if you go back and check QB64's history, we've always been inconsistent with what value we returned with a CONST and &H, &B, &O.   SDL and early GL versions (1.0 for certain) all returned an UNSIGNED value.  Somewhere along the way, (at least in version 2.0.2 by my testing), we reverted to returning SIGNED values.  QB64PE inherited that behavior from 2.0.2, which was our clone base, and has always returned SIGNED values until the last release (3.9), which one again tried to bring us back to UNSIGNED values.

Since at least 2.0.2, and for all of QB64PE's history, we've returned those SIGNED values, and nobody has complained or apparently noticed.  It's only the last release which showcased the issue with the internal eval (QB64 actually has half a dozen places where it calculates these figures as it parses different spots of code), and so reverting back to what was standard before that really shouldn't affect anyone overly much.

If you've never had issues with QB64PE before and CONST, then chances are you won't have any once the patch gets approved, merged, and pushed into the repo.

I was thinking from 1.0 to 3.9 we'd always returned unsigned values.  I was wrong on that, as some historical version testing proved to me.  1.0 returned unsigned values.  Somewhere along the way, 2.0 and up started returning unsigned values.  It was only 3.9 where we once again swapped back over to unsigned values.  So swapping back for 3.11, when we release it, really shouldn't cause the disturbance that I was imagining it might.



Looks like this dumpster fire is going to actually turn out to be a false alarm for us.    (Though it does go to help highlight that if you want to be certain of what values you're getting back from hex, you should still **always** use the proper type symbol yourself.)

[bplus]

It was broken long before when using hex and comparing a Point color to it, so I don't expect it to effect much. l already started using ~& or RGB32() colors to fix graphics I was attempting.

To me this is a long awaited fix, I doubt it will make anything incompatible?

Well, your Sudoku triggered it with me; all colors were black 
With my own code, I only had a few of these and only with colors like Const CLR_RED = &hFFFF0000
now replaced all with  Const CLR_RED = &hFFFF0000~& or Const CLR_RED = _RGB32(255,0,0)

Thanks for reporting, now fixed:
https://qb64phoenix.com/forum/showthread...0#pid22360

So the change occurred after 2020.

[Kernelpanic]

And here: https://qb64phoenix.com/forum/showthread...262&page=6

I am slowly losing perspective. What is now correct:
1. QB45 delivers an incorrect result, and since QB64 wants to be 100% compatible with QB45, this error should now be implemented in QB64.
2. QB45 gives the correct result, QB64 the wrong one.

If 1.: Why should implement false output in QB64 now? Is that not an overkill only for the compatibility?