FOR/NEXT or big number bug?

[RhoSigma]

The following example quickly shows the issue, although the loop variable and literal numbers are explicitly marked as _UNSIGNED _INTEGER64 by using the respective type suffix (~&&), the first loop is skipped completely as it obviously want run from 0 TO -1 instead of 0 TO 18446744073709551615. The second loop does exclude the usual sign bit (&H7F... instead of &HFF...) and is therfor correctly entered.

This happens only with _UNSIGNED _INTEGER64, while it works correctly for (_UNSIGNED) LONG, INTEGER and _BYTE, where both loops are entered. By this fact I think it's rather a FOR/NEXT issue than a general _UNSIGNED numbers issue.

Code: QB64: [Select]

1. inside% = 0
2. FOR n~&& = 0 TO &HFFFFFFFFFFFFFFFF~&&
3.     IF NOT inside% THEN
4.         inside% = -1
5.         EXIT FOR
6.     END IF
7. NEXT n~&&
8. IF inside% THEN PRINT "I was inside the 1st loop."
9.  
10. inside% = 0
11. FOR n~&& = 0 TO &H7FFFFFFFFFFFFFFF~&&
12.     IF NOT inside% THEN
13.         inside% = -1
14.         EXIT FOR
15.     END IF
16. NEXT n~&&
17. IF inside% THEN PRINT "I was inside the 2nd loop."
18.  
19. END
20.  

[Cobalt]

just what are you working with that has 18.446 quintillion values?

[RhoSigma]

Just playing around :), wanted the maximum possible integer range to find all "Perfect Numbers" in it (https://en.wikipedia.org/wiki/Perfect_number).

However, it's simply incorrect, that &HFFFFFFFFFFFFFFFF~&& is interpreted as -1, if the type suffix clearly states it shall be UNSIGNED and as

PRINT &HFFFFFFFFFFFFFFFF~&&

does correctly print 18446744073709551615, I guess it's just a misinterpretation by FOR/NEXT.

[SMcNeill]

This makes sense, if you take a moment to think about it logically...

FOR i = 1 TO 10.

How high does i increment to in the above snippet?

When finished, i = 10 + 1.

Code: QB64: [Select]

1. FOR i = 1 TO 10
2. NEXT
3. PRINT i

Since you're trying to do a FOR loop from 0 to &HFFFFFFFFFFFFFFFF~&&, you're actually counting to &HFFFFFFFFFFFFFFFF~&& + 1 -- which is going to overflow and not work as you're intending.

[SMcNeill]

Actually, scratch that...

If you look inside maindata.txt, at our translated code, it's obvious what the issue is, in this case:

Code: QB64: [Select]

1. static int64 fornext_value2;
2. static int64 fornext_finalvalue2;
3. static int64 fornext_step2;
4. static uint8 fornext_step_negative2;

The variables are declared as int64 values and not unsigned int64s.  The limit is going to be INT64 bounds, unless somebody wants to go in and track down the relevant lines in the source to properly translate the values for us when uint64s are needed instead.