Local 2D Array of strings crash (*solved*)

I seem to be having some issues trying to use a 2D array of Strings in some cases, but unfortunately I don't seem to be able to figure out what they are. A piece of code which seems to work fine in isolation fails when I put it into my main program with screen corruption and a crash. Is a 2D array of Strings 'bad form' for some reason?

In the end I replaced it with a 2D array of UBYTEs instead which worked okay (and was probably less wasteful, tbh - I was only storing single characters anyway). If I figure out a decent way to reproduce the crash without it being embedded in a huge chunk of other stuff then I'll post it. It could well be something silly that I've done elsewhere in the program.

While I'm here, could someone clarify what is okay to declare within a SUB? I don't seem to have any problems declaring normal variables (e.g. DIM test AS UBYTE) within a SUB, but I seem to have crash issues if I try to declare and use an array (e.g. DIM test(2,2) AS UBYTE). Is it actually legal to try and do that?

This code, for example, crashes unless I move the UBYTE array outside of the SUB:

  Code:

test()


SUB test
   DIM xpos as UBYTE
   DIM ypos as UBYTE
   DIM scrdata(22, 32) AS UBYTE

   CLS

   FOR ypos = 0 TO 21
      FOR xpos = 0 TO 31
         scrdata(ypos, xpos) = 65
      NEXT xpos
   NEXT ypos

   PRINT "Done."
   PAUSE 0

   CLS
   FOR ypos = 0 TO 21
      FOR xpos = 0 TO 31
         PRINT AT ypos, xpos; CHR(scrdata(ypos, xpos))
      NEXT xpos
   NEXT ypos
END SUB

Sorry if the answer here is obvious, I'm still getting used to how things work.

[boriel]

Since this is a different issue, I've moved it to a new topic
And yes, this is a another bug. Let me investigate it...

Thanks, Boriel! Sorry for finding another bug.

[boriel]

Thanks, Boriel! Sorry for finding another bug.

No, thanks to you.

It seems fixed now. Please, download new version r1606 and test it.

Thanks, I'll grab that now and give it a trial run later on. I'll let you know how I get on!

Hmm... is the zip package not updated? I downloaded it and installed but it reports back as 1603 rather than 1606. Sorry to be a pest.

[boriel]

Please, check it anyway. Version number is not updated automatically (a subversion problem I'm trying to fix up). So even if it reads 1.2.6-r1606 (or the whatever) it might be the last version.

You can also update to the lastest trunk / developmnet with:
svn update https://boriel.homeip.net/svn/zxbasic Current version is rev1666

Okay, I'll test it regardless. I'm don't think SVN will work through my company's firewall, but I should be able to do that from home later on if needs be.

[boriel]

I'm not saying you to try the /trunk development/ version with subversion, but to run your program with the version you downloaded today.
You can download it here:
http://www.boriel.com/wiki/en/index.php ... IC:Archive

Have you compiled it? Even if it has the same version number it's a *different* new one.

Now that I've had a chance to look at the files a bit more carefully I can see that some of them are different to the previous version despite the version number being the same, so no problems there - sorry for the confusion!

And the good news is that the bug appears to be fixed - I managed to compile and run the test program above (and some other ones that I didn't post) without any errors or crashes.

Many thanks for your continued hard work, boriel! It's very much appreciated!

[boriel]

Ok

Thanks a lot (this bug is marked as fixed, although I still have to make some changes in the compiler).