The issue here is that QB64 doesn't have one central place where it calculates &H, &B, and &O values for us. The functionality for those functions was apparently added in piece by piece as various other commands came into being.
CONST has a separate &H handler.
VAL has a separate &H handler.
DATA has a separate &H handler.
Normal variable evaluations have a separate &H handler.
(other things probably do as well, but my brain isn't listing them all for me at the moment).
And some of these places return signed values, and some return unsigned values, and it's all just a mess. (Heck, for that much, what these various things return to us has changed inconsistently over the various versions. QB64-SDL and shortly after returned unsigned values with CONST. Then sometime after, it swapped to signed values. 3.10 reverted us back to unsigned values, as I posted on, thinking it'd always been that way. 3.11 has reverted that back to signed...)
And now that we're noticing the issue, it's a real headache to sort out what to do about it. There's a LOT of code affected, in a lot of different places. Do we go in and tweak them all, one by one, to make them QB45 compatible? Or do we whistle innocently and leave them so they remain QB64-compatible?
QB64 has now been around as long as QB45 ever was, and that now leads us to a condundrum: Do we now go in and change these issues now that we've finally noticed them, thereby breaking any QB64 program which relies on them with their current quirky behavior? Or do we leave them alone so folks program will continue to run like always, without them having to go back and rewrite their QB64 stuff once again?
At the moment, we've decided to just leave things be. Nobody has really been reporting issues with the current behavior. Nobody is really clammering for a fix to maintain 100% compatibility. There's a LOT of code which would need to be changed to make everything behave universally the same, and there honestly appears to be very little demand from the user base, wanting us to invest the time and manpower into working on the &H, &B, &O stuff.
For now, folks should just make a note somewhere in the back of their brains that says, "QB45 &H, &B, &O may not be 100% compatible in all cases. The values returned may be unsigned instead of signed, so if I ever compile 40-year old code, then I should keep that in mind in case any issues arise."
Biggest takeaway I think folks should take from all this is: &H, &B, &O values should always have an ending suffix to be 100% certain to never have any issues with them in your code.
CONST has a separate &H handler.
VAL has a separate &H handler.
DATA has a separate &H handler.
Normal variable evaluations have a separate &H handler.
(other things probably do as well, but my brain isn't listing them all for me at the moment).
And some of these places return signed values, and some return unsigned values, and it's all just a mess. (Heck, for that much, what these various things return to us has changed inconsistently over the various versions. QB64-SDL and shortly after returned unsigned values with CONST. Then sometime after, it swapped to signed values. 3.10 reverted us back to unsigned values, as I posted on, thinking it'd always been that way. 3.11 has reverted that back to signed...)
And now that we're noticing the issue, it's a real headache to sort out what to do about it. There's a LOT of code affected, in a lot of different places. Do we go in and tweak them all, one by one, to make them QB45 compatible? Or do we whistle innocently and leave them so they remain QB64-compatible?
QB64 has now been around as long as QB45 ever was, and that now leads us to a condundrum: Do we now go in and change these issues now that we've finally noticed them, thereby breaking any QB64 program which relies on them with their current quirky behavior? Or do we leave them alone so folks program will continue to run like always, without them having to go back and rewrite their QB64 stuff once again?
At the moment, we've decided to just leave things be. Nobody has really been reporting issues with the current behavior. Nobody is really clammering for a fix to maintain 100% compatibility. There's a LOT of code which would need to be changed to make everything behave universally the same, and there honestly appears to be very little demand from the user base, wanting us to invest the time and manpower into working on the &H, &B, &O stuff.
For now, folks should just make a note somewhere in the back of their brains that says, "QB45 &H, &B, &O may not be 100% compatible in all cases. The values returned may be unsigned instead of signed, so if I ever compile 40-year old code, then I should keep that in mind in case any issues arise."
Biggest takeaway I think folks should take from all this is: &H, &B, &O values should always have an ending suffix to be 100% certain to never have any issues with them in your code.