SELECT - CASE limit ?

Previous topic - Next topic

dbots

Hi, I have the following code :
Code (glbasic) Select

DIM arr_icons[5][3];
.......
SELECT stop1
CASE 0
arr_icons[1][1] = "KA"; arr_icons[1][2] = "LE"; arr_icons[1][3] = "7";
CASE 1
arr_icons[1][1] = "BE"; arr_icons[1][2] = "KA"; arr_icons[1][3] = "LE";
CASE 2
arr_icons[1][1] = "DA"; arr_icons[1][2] = "BE"; arr_icons[1][3] = "KA";
CASE 3
arr_icons[1][1] = "CH"; arr_icons[1][2] = "DA"; arr_icons[1][3] = "BE";
CASE 4
arr_icons[1][1] = "KA"; arr_icons[1][2] = "CH"; arr_icons[1][3] = "DA";
CASE 5
arr_icons[1][1] = "7";  arr_icons[1][2] = "KA"; arr_icons[1][3] = "CH";
CASE 6
arr_icons[1][1] = "MH"; arr_icons[1][2] = "7";  arr_icons[1][3] = "KA";
CASE 7
arr_icons[1][1] = "BE"; arr_icons[1][2] = "MH";  arr_icons[1][3] = "7";
CASE 8
arr_icons[1][1] = "DA"; arr_icons[1][2] = "BE";  arr_icons[1][3] = "MH";
CASE 9
arr_icons[1][1] = "LE"; arr_icons[1][2] = "DA";  arr_icons[1][3] = "BE";
CASE 10
arr_icons[1][1] = "CH"; arr_icons[1][2] = "LE";  arr_icons[1][3] = "DA";
CASE 11
arr_icons[1][1] = "MH"; arr_icons[1][2] = "CH";  arr_icons[1][3] = "LE";
CASE 12
arr_icons[1][1] = "PO"; arr_icons[1][2] = "MH";  arr_icons[1][3] = "CH";
// CASE 13
// arr_icons[1][1] = "CH"; arr_icons[1][2] = "PO";  arr_icons[1][3] = "MH";
// CASE 14
// arr_icons[1][1] = "KA"; arr_icons[1][2] = "CH";  arr_icons[1][3] = "PO";
// CASE 15
// arr_icons[1][1] = "DA"; arr_icons[1][2] = "KA";  arr_icons[1][3] = "CH";
// CASE 16
// arr_icons[1][1] = "PO"; arr_icons[1][2] = "DA";  arr_icons[1][3] = "KA";
// CASE 17
// arr_icons[1][1] = "MH"; arr_icons[1][2] = "PO";  arr_icons[1][3] = "DA";
// CASE 18
// arr_icons[1][1] = "7";  arr_icons[1][2] = "MH";  arr_icons[1][3] = "PO";
// CASE 19
// arr_icons[1][1] = "LE"; arr_icons[1][2] = "7";   arr_icons[1][3] = "MH";
ENDSELECT

in a sample game I write and it executes well.
But, when I remove any of the commented CASE lines, so if I have more than 13 active CASEs inside my SELECT, then application hangs when started... Any ideas ?

Moru

#1
Hello!

If you activate debugging you will see that you are out of dim-array. This means you have too little space for your array.

DIM arr_icons[5][3];    <--- change to [5][4] to make space. Arrays start counting from 0 so 4 spaces means 0 - 3 is possible

dbots

Thanks Moru, you are absolutely right !
I activated debugging and I have :
Code (glbasic) Select

Injection started

bounds: [   5][   3]
access: [   1][   3]
.......Out of DIM array

Can you please explain what all these mean ? What I don't understand is that I don't fill the array... it's a set of CASES whose code does not even get executed so array is not filled and cause any memory problem.
Why it's "Out of DIM array" ?

Moru

When I try your code with stop1 = 17 I get problems. If I set stop1 = 55 I have no problems. If you set a breakpoint (F9) just before the select code and then step through (ctrl+F10) you will see what really happens, can't say more without having your complete source.

dbots

OK I found it.
The problem is that I declare :
DIM arr_icons[5][3];

but then I use :
arr_icons[1][3] = ...

The second dimension goes from 0 to 2.

What happened with commented CASEs was because stop1 gets a random value from my code so when its value would not belong to any CASE then the erroneous arr_icons[1][3] would not execute.

Shouldn't the compiler find that ?

Thanks for the help !

Moru

No, there is nothing wrong with a case that has no target. If you want something to always happen if there is no matching case, you need to use DEFAULT as the last CASE.

dbots

Quote from: Moru on 2013-Mar-30
No, there is nothing wrong with a case that has no target. If you want something to always happen if there is no matching case, you need to use DEFAULT as the last CASE.
No, I didn't mean that there is something wrong with a CASE that has no target.
Simply, when the CASE has no target (whose target causes the problem due to mine wrong reference to array's dimension) then all executed well and now I can understand it why.

My last question was that maybe the compiler should understand that the array's dimension I use is out of declared dimension and through some error before linking. Anyway it's all clear now.

Ian Price

Yeah, I've mentioned GLB's lack of throwing an "ARRAY OUT OF BOUNDS" error message a couple of times (in fact this was discussed just recently). Whenever GLB crashes out, I automatically expect it to be an out of array error nowadays as I've seen it so often! :P
I came. I saw. I played.

kanonet

The compiler could notice a few out of bounds errors, but not all, cause if you access an array with a variable as index that gets changed on the fly or depends on user input - how should the compiler detect this? There is no real point in adding a check that only catches a few errors of same kind. This is what the debugger is for, simply use it and you know what was the problem.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Moru

Always run with debugger on. There is no reason not to use the debugger, that's what it's there for. Exactly this problem. You can't complain that it's not doing it's job if you don't use it :-) There is no way the compiler can catch this error anyway and for speed reasons you will have to check for this error yourself if you want to avoid it.

Ian Price

No other language I've ever used ignores this error - whether debugger is used or not, an error is an error and the user should be notified. Even if it just spits out "Unexpected/unknown error", rather than just stopping running.
I came. I saw. I played.