Confirmation of proper behavior in SELECT\CASE

[Cobalt]

Ok I think I know what is going on here but I just wanted more input on this,

Is this how SELECT\CASE in QB64 is supposed to handle this?

Code: QB64: [Select]

1. DIM TEST AS _BYTE
2. TEST = &HFF
3. 'TEST = &H80
4. 'TEST = &H40
5. 'TEST = &H08
6. 'TEST = &H01
7.  
8. SELECT CASE TEST
9.  CASE &HFF 'flaged conversations
10.   PRINT "FF is GTG!"
11.  CASE &H80
12.   PRINT "80 is GTG!"
13.  CASE &H40 'shops
14.   PRINT "40 is GTG!"
15.  CASE &H08 'church
16.   PRINT "08 is GTG!"
17.  CASE &H01 'standard dialog
18.   PRINT "01 is GTG!"
19. END SELECT
20.  
21. PRINT "&H"; HEX$(TEST)
22. PRINT TEST
23. C~%% = TEST
24. PRINT C~%%
25. T%% = &HFF
26. PRINT T%%

Its not catching the first 2 CASE scenarios here. least not on my side, V1.5 stable

I think it may treating the &H as an unsigned value?(&H80 and up sets bit 7 which makes it a negative in a signed scenario)
should it be treating the values differently? if you assign TEST to an unsigned variable it doesn't change it, the BITs are still set properly so why isn't SELECT\CASE matching it? if you put &HFF into a signed variable it becomes -1.

From my perspective &HFF is both -1 and 255 based on the SELECT variable used; SIGNED or UNSIGNED.

Its an easy fix of adding _UNSIGNED to my UDT in the actual code, but I just wanted to make sure the SELECT\CASE was behaving properly, which I think it might be but I'd rather have input from others on that one to make sure.

[SpriggsySpriggs]

I'd just make TEST an unsigned byte because when you are doing the case, &HFF is going to be pointing to 255 while your variable will be overflowed and not match the value. That's my guess

[SMcNeill]

Code: QB64: [Select]

1. Dim TEST As _Byte
2. TEST = &HFF
3. 'TEST = &H80
4. 'TEST = &H40
5. 'TEST = &H08
6. 'TEST = &H01
7.  
8. Select Case TEST
9.     Case &HFF%% 'flaged conversations
10.         Print "FF is GTG!"
11.     Case &H80%%
12.         Print "80 is GTG!"
13.     Case &H40%% 'shops
14.         Print "40 is GTG!"
15.     Case &H08%% 'church
16.         Print "08 is GTG!"
17.     Case &H01%% 'standard dialog
18.         Print "01 is GTG!"
19. End Select

Assign the variable type to your &H-math manually, like I've done above, and QB64 won't have to guess at what that value is supposed to be.

[Cobalt]

I'd just make TEST an unsigned byte because when you are doing the case, &HFF is going to be pointing to 255 while your variable will be overflowed and not match the value. That's my guess

Yeah, I mean that is what I ended up doing.  QB64 defaults to LONG with undefined variables and constants or SINGLEs? so &HFF is probably being treated as a LONG or SINGLE even though the comparison variable is BYTE. I'd almost think it would want to match the CASE type with the SELECT type.
In terms of BITs they are identical,at BYTE width, &HFF = 11111111, -1=11111111, and 255=11111111. So in a bit-wise comparison they should always be =.
Been doing a lot of BIT work in my game lately, so probably why I was taken aback by this.

Assign the variable type to your &H-math manually, like I've done above, and QB64 won't have to guess at what that value is supposed to be.

Oh yeah, I forgot about that. Been a long time since I have used that method.


✅Thanks for the feedback guys.✅

[NOVARSEG]

I looks like  the way CASE is interpreting &HFF

Code: QB64: [Select]

1. DIM TEST AS _BYTE
2. TEST = &HFF
3. PRINT TEST
4.  
5. 'TEST = &H80
6. 'TEST = &H40
7. 'TEST = &H08
8. 'TEST = &H01
9.  
10. SELECT CASE TEST
11.     CASE -1 'flaged conversations
12.         PRINT "FF is GTG!"
13.     CASE &H80%%
14.         PRINT "80 is GTG!"
15.     CASE &H40%% 'shops
16.         PRINT "40 is GTG!"
17.     CASE &H08%% 'church
18.         PRINT "08 is GTG!"
19.     CASE &H01%% 'standard dialog
20.         PRINT "01 is GTG!"
21. END SELECT
22.