Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: RhoSigma on February 19, 2019, 07:11:51 pm

Title: FOR/NEXT or big number bug?
Post by: RhoSigma on February 19, 2019, 07:11:51 pm
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.  
  20.  
Title: Re: FOR/NEXT or big number bug?
Post by: Cobalt on February 20, 2019, 07:16:14 pm
just what are you working with that has 18.446 quintillion values?
Title: Re: FOR/NEXT or big number bug?
Post by: RhoSigma on February 21, 2019, 02:25:50 am
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.
Title: Re: FOR/NEXT or big number bug?
Post by: SMcNeill on February 21, 2019, 06:28:15 am
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

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.
Title: Re: FOR/NEXT or big number bug?
Post by: SMcNeill on February 21, 2019, 06:34:56 am
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.
Text Only | Text with Attachments