Arrays and OPTION BASE 1 (BUG?)

[RhoSigma]

Hi all,
wanna ask for opinions, if this should be changed or accepted as is (maybe for compatiblity, if anybody could check the behavior in QBasic/QB45).

If OPTION BASE 1 is in effect, then in QB64 we can still use the 0-index, if the array was hard indexed as DIM array(0 TO 10). However, I found that we can still do DIM array(0) without any error even with OPTION BASE 1 in effect. But it gives a subtle behavior then, obviously the DIM respects the index 1 as the array's lowest possible index (LBOUND) but put the 0-index into the UBOUND, hence it does reverse the logical order of LBOUND and UBOUND. More than that, if we try to assign a value to either of the 0- or 1-index, then we get a "Subscript out of range" for both indicies.

Code: QB64: [Select]

1. OPTION BASE 1
2.  
3. DIM a$(0 TO 10)
4. DIM b$(0) '-----> IMHO this should rather give an "Illegal function call",
5. '                 if OPTION BASE 1 is in effect.
6.  
7. PRINT "       ", "a$()", "b$()"
8. PRINT "LBOUND:", LBOUND(a$), LBOUND(b$)
9. PRINT "UBOUND:", UBOUND(a$), UBOUND(b$)
10.  
11. b$(0) = "0" '---> "Subscript out of range in Line 11" (press "Continue")
12. b$(1) = "1" '---> "Subscript out of range in Line 12"
13.  
14.  

[SMcNeill]

There's a bug in there somewhere, and it's not just in OPTION BASE 1.

Try this very simple little demo:

Code: QB64: [Select]

1. DIM a$(-3)
2.  
3. OPTION BASE 1
4.  
5. DIM b$(0)
6.  
7.  
8.  
9.  
10.  
11. PRINT "       ", "a$()", "b$()"
12. PRINT "LBOUND:", LBOUND(a$), LBOUND(b$)
13. PRINT "UBOUND:", UBOUND(a$), UBOUND(b$)
14.  
15. b$(0) = "0" '---> "Subscript out of range in Line 11" (press "Continue")
16. b$(1) = "1" '---> "Subscript out of range in Line 12"
17.  

Unlike your example which at least tosses errors, if we try and DIM an array with a negative index, with OPTION BASE being 0, the program compiles and executes just fine -- and then immediately crashes and closes in the blink of an eye with no error message!

(Past experience has taught me that Linux would actually probably be smarter and toss an error message here which read something really useful like "Seg Fault," or such, whereas Windows just dies on us.)

Easiest fix is probably to just have the IDE toss an error when using DIM with a variable and the LBOUND > UBOUND for it.

[Cobalt]

Programmers need to be held accountable for something, if you have OPTION BASE 1 and try to DIM Array(0) that is not the IDE or Compiler's problem there, that is the Programmers! Though my Windows does give error information when it crashes('access violation').

[RhoSigma]

Programmers need to be held accountable for something, if you have OPTION BASE 1 and try to DIM Array(0) that is not the IDE or Compiler's problem there, that is the Programmers! Though my Windows does give error information when it crashes('access violation').

I totally agree, unfortunately it never prevented people from doing those things sometimes, even if it's only by mistake. From that point of view at least an IDE warning would make sense.

[SMcNeill]

Programmers need to be held accountable for something, if you have OPTION BASE 1 and try to DIM Array(0) that is not the IDE or Compiler's problem there, that is the Programmers! Though my Windows does give error information when it crashes('access violation').

The problem you’re overlooking is library files.  I write a lot of my library files with REDIM variable(0) AS whatever, up in the top of the code, and then set the size to exactly what’s needed to use minimal memory inside a SUB/FUNCTION.  Since 99% of users never bother with OPTION BASE 1, it’s seldom an issue.

For that 1% who does use OB1 though, it’d be nice if the IDE tossed them a warning about the issue, before they go and spend ages trying to sort out what the glitch is in their code.  ;)

[TempodiBasic]

Hi

from wiki I learn that
OPTION BASE {0|1} sets the lower index of an array when it is not declared.

This statement affects array declarations where the lower bound of a dimension is not specified.
When used, OPTION BASE must come before any array declarations (DIM) to be affected.
By default, the lower bound for arrays is zero, and may be changed to one using the statement.
Otherwise, arrays will be dimensioned from element 0 if you DIM just the upper bounds.
You can also set other array boundaries by using TO in the DIM declaration such as DIM array(5 TO 10)

so the issue is only for array declared without DIM & TO
and this tells also that in the same code can be together arrays with only Upper limit, on these OPTION BASE works, with arrays with upper and lower limits declared, on these OPTION BASE doesn't work!

in the while I can affirm that on my PC (windows 10) the code of Steve runs with no output
this is the main.txt of internal folder of QB64...

this is the source code

Code: QB64: [Select]

1. DIM a$(-3)
2.  
3. OPTION BASE 1
4.  
5. DIM b$(0)
6.  
7.  
8.  
9.  
10.  
11. PRINT "       ", "a$()", "b$()"
12. PRINT total(LBOUND(a$), UBOUND(a$)), total(LBOUND(b$), UBOUND(b$))
13. SLEEP 2
14. PRINT "LBOUND:", LBOUND(a$), LBOUND(b$)
15. PRINT "UBOUND:", UBOUND(a$), UBOUND(b$)
16. SLEEP 2
17. b$(0) = "0" '---> "Subscript out of range in Line 11" (press "Continue")
18. b$(1) = "1" '---> "Subscript out of range in Line 12"
19.  
20. FUNCTION total (min, max)
21.     total = max - min + 1 ' thanks to Steve
22. END FUNCTION

but also this code gains the message of error at first run and then no output situation

Code: QB64: [Select]

1. DIM a$(-3)
2.  
3. PRINT "       ", "a$()", "b$()"
4. PRINT total(LBOUND(a$), UBOUND(a$))
5.  
6. FUNCTION total (min, max)
7.     total = max - min + 1 ' thanks to Steve
8. END FUNCTION

....no OPTION BASE in this last code!

Moreover IMHO  the use of OPTION BASE must be declared obsolete or deprecated like it is done in other languages...
so who likes to type code in the old manner without using DIM + TO  is free to do it, but he knows that his code brings into itself some potential glitches!

[TempodiBasic]

another bit of experience on OPTION BASE declaring an array with no lower limit or with upper limit under OptionBase option.

Code: QB64: [Select]

1. ON ERROR GOTO noItem
2. DIM a(3), c(0)
3. PRINT "ITEM    A     C"
4. FOR k = 0 TO 3
5.     PRINT k; "    ";
6.     PRINT a(k); "   ";
7.     PRINT c(k)
8. NEXT
9. PRINT "--------------------------------"
10. OPTION BASE 1
11. DIM a1(3), c1(0)
12. k = 0
13. PRINT "ITEM    A1     C1"
14. FOR k = 0 TO 3
15.     PRINT k; "    ";
16.     PRINT a1(k); "   ";
17.     PRINT c1(k)
18. NEXT
19.  
20. END
21.  
22. noItem:
23. PRINT "Error"
24. RESUME NEXT
25.  

 [ You are not allowed to view this attachment ]  
it seems that OptionBase works like a macrodefinition and not as a command that set the lower limit of the array, in fact in the output of the second array, declared handly with (0) against OptionBase setting , we get error also at first item (1)
and so , like Steve said before , we cannot access to the variable array(0) .
The solution is to transform the OPTIONBASE setting into a Macrodefinition so that all lower limit of array not declared with DIM + TO are set to 1. 
(so much work for a old command not so yet used) :-(