Print &HFFFF, Hex$(&HFFFF)



Dim l As Long, i As _Integer64

l = &HFFFF

i = &HFFFF

Print l, Hex$(l)

Print i, Hex$(i)

Quote:-1        FFFF
-1        FFFFFFFF
-1        FFFFFFFFFFFFFFFF

Const blue = &HFF0000FF

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

Quote:FFFFFFFF0FF000F1          FF0000FF

Quote:@RhoSigma - Wish people would just once look there befor complaining, its rather sucking to maintain the wiki and knowing nobody use it when needed.

(12-27-2023, 11:02 PM)SMcNeill Wrote: 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:

Quote:-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:

Quote: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.)

Const Wert1 = 344 '-> Integer

Const Wert2 = 3.44 '-> Single, simplest type



'Error

'Const Stadt = Berlin



'Correct

Const Stadt = "Berlin"



Print Wert1

Print Wert2

Print Stadt

(12-29-2023, 02:09 PM)Kernelpanic Wrote: The QuickBasic 4.5 manual says the following about constants:

The type constant is either explicit through the type identifier, or determined by the type of expression. Without a type identifier, the simplest type in which the constant can be represented is always assigned.

Strings are always define as string constants.

Code: (Select All)

Const Wert1 = 344 '-> Integer

Const Wert2 = 3.44 '-> Single, simplest type



'Error

'Const Stadt = Berlin



'Correct

Const Stadt = "Berlin"



Print Wert1

Print Wert2

Print Stadt

Quote:The type constant is either explicit through the type identifier, or determined by the type of expression. Without a type identifier, the simplest type in which the constant can be represented is always assigned.

(12-29-2023, 09:16 AM)SMcNeill Wrote: [quote="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." pid="22297" dateline="1703718120"]

(12-29-2023, 08:53 PM)bert22306 Wrote:

(12-29-2023, 09:16 AM)SMcNeill Wrote: Damn! Thing is, I always use hex the way you had "always assumed." Always hex number unsigned. I guess, no huge big deal, it's going to take some trial and error to see what old programs of mine will break. I guess I never ran into the problem in my Qbasic days.

Wait. If I do x = Val("&h" + "ffff")

Will I still get x = 65535