QB664PE v3.10.0 is now live for X-Mas!!

[SMcNeill]

It's actually a case where doing a fix allowed it to break.

In the past, &H would error out, skip out of the manual evaluation process, and go into the automatic catch-all evaluation routines (which is where we do things such as various string manipulation like "a" + "b" which would, of course, be "ab".)  By fixing it so that it no longer glitches and errors out like it used to, we're now properly returning the value that we tell it to give us -- which is, the improper value!

Let me showcase part of the issue for you guys:

Code: (Select All)

Print &HFFFF, Hex$(&HFFFF)



Dim l As Long, i As _Integer64

l = &HFFFF

i = &HFFFF

Print l, Hex$(l)

Print i, Hex$(i)

Now the results here are a print out of:

-1        FFFF
-1        FFFFFFFF
-1        FFFFFFFFFFFFFFFF

The problem here?

This goes back to the QBASIC roots of the language, and which we have to follow to maintain backwards compatibility.  QBASIC didn't have any _UNSIGNED numbers, so all values had to be represented as signed numbers.

FFFF was considered to be a 2-byte integer, and as a signed integer, the value is indeed -1.

The problem comes from the fact that -1 as an integer is represented as FFFF, and as an long it's represented as FFFFFFFF...  And if we turn that hex representation into an unsigned value, it becomes much different!    65535 vs 4billion-something!!

So our internal math eval is now properly reading the values for us, but it's improperly returning everything as an unsigned integer64 back to us.

&HFFFF would return 65535, when -- by default in QBASIC and QB64 -- it should return -1.
&HFFFFFFFF would return the 4billion-something value, when it too should actually return -1.  

(One is just -1 as an integer, while the other is -1 as an long.)

So that's one glitch here.  I take full responsibility for this one.  I've just always *assumed* when working with hex, one was using *unsigned* values.  QBASIC didn't have unsigned values, so the result has to return as signed values to be backwards compatible.   This part of the glitch is 100% on me, and should be rather simple to fix.

---

Now, unrelated to this signed/unsigned glitch, our fix is also pointing out that there are now instances where a negative sign is getting appended to the values before we evaluate them.  Matt has hunted this glitch down for us, and should be able to sort it out soon(tm).

(Note:  SOON in this case is SOON(TM!!), as this is the heart of the holiday season and everyone is busy as heck!  We'll get to it, as soon as we can get to it.   )

If you want a good demo of both glitches in action, just run this little code:

Code: (Select All)

Const blue = &HFF0000FF

Print Hex$(blue), Hex$(-blue)

The result you get is:

FFFFFFFF0FF000F1          FF0000FF

That first value (which I may have copied wrong --/shrug -- ) is basically the unsigned integer64 value of NEGATIVE blue.  The negative glitch is hitting the value we specify, as well as the fact that it's being returned as an integer64 value to us, by default.

That second value goes to show that if we negate that number, once it becomes positive, it is -- indeed -- the value we assigned to blue.  (It's just an unsigned integer64 value, but hex$ strips off those leading 8 zeros, so you'd never actually know it was an unsigned int64 unless you did a LEN on it, or some nice Steve told you...)

---

So multiple fixes are required for this:

1) To fix the return type so that it's a signed value, to match QB45 behavior.
2) To remove that improper negation which is happening to certain values with &H.  (&B and probably &O as well.)

Fixes for this here has been pushed into the repo for testing and approval of the other devs.  If all goes good and the fix for this doesn't break something somewhere else (which is entirely possible with CONST, as complicated as it's became), it should get merged into the repo in the next few days and then be availble in the next release we offer.