ELSE issue? (*solved*)

[LTee]

Have you had enough of me yet? :-D

I'm having a weird issue with ELSE, but I'm not sure if I'm doing something wrong or not. Take a look at this test program:

Code:

dim num as ubyte

cls
num = 1
test()
num = 2
test()
num = 3
test()
num = 4
test ()

sub test
    IF num = 1 THEN
        PRINT "1"
    ELSEIF num = 2 THEN
        PRINT "2"
    ELSEIF num = 3 THEN
        PRINT "3"
    ELSE
        PRINT "X"
    END IF
    PRINT "---"
end sub

I would expect the output from this to be like this:

Code:

1
---
2
---
3
---
X
---

But it's actually like this:

Code:

1
---
2
---
3
X
---
X
---

Condition "3" is running correctly, but the final ELSE block is also being processed so you get two lines output if num is 3. Have I messed up the syntax there? The behaviour is certainly different to how it used to be, as an old program that used to be okay is now failing.

I've tried this in 2100 and also 1866 and it does the same in both, so it must've been a while since I compiled it! :-)

[boriel]

It's another, and this one is related to the ELSEIF sentence (not very tested sorry). This is really an important one. Let me fix it... and again, thanks! :oops:

[LTee]

I'll try not to find anything else today. :-D

[boriel]

I've located the bug. But this one is harder to fix. :oops: (still working on it...)

[boriel]

Ok, seems to be fixed now. Please, download 1.2.7-r2105, as always, from the Download page and check, please. :roll:

[LTee]

Looking good! All the tests I've run so far have worked great.

Great work as usual, boriel - thanks! :-)

[boriel]

Thanks! So should we release 1.2.7 final and go for 1.2.8 (e.g. Dynamic arrays or read/data/restore or whatever new feature?)

[LTee]

I certainly don't have any more problems at the moment, and the ones I have had have been pretty obscure (apart from the -Z thing, he he). All seems good for a release from my point of view.

[boriel]

I certainly don't have any more problems at the moment, and the ones I have had have been pretty obscure (apart from the -Z thing, he he). All seems good for a release from my point of view.

Done. Latest 1.2.7 release fixes a bug with DRAW and OVER 1.

I've started 1.2.8 and, again, it will be a major code refactorization (headed towards 2.x release). In this release, I think I could introduce dynamic arrays, or probably READ/DATA/RESTORE and GOTO/GOSUB <variables>...
But currently 1.2.8 just does the same 1.2.7 does (Just rearranged yesterday some objects and files). Let's hope... it works :|

[LTee]

Will download and test asap. :-)

[LTee]

Everything seems to be compiling and running okay with the release 1.2.7!

Just one minor difference I can see, and I'm not sure what the implications of this are. When I compile the project that requires -Z, I now get an extra 'WARNING' from the compiler, which is this:

Code:

alloc.bas:73: warning: FUNCTION 'reallocate' declared as FASTCALL with 2 parameters

The Wiki says that FASTCALL functions can only have a single parameter, and sure enough 'reallocate' in alloc.bas has two parameters. This doesn't seem to affect anything in my program, but is this a problem? I note that in the previous build the function was the same, but the warning wasn't generated. :-D

[boriel]

Everything seems to be compiling and running okay with the release 1.2.7!

Just one minor difference I can see, and I'm not sure what the implications of this are. When I compile the project that requires -Z, I now get an extra 'WARNING' from the compiler, which is this:

Code:

alloc.bas:73: warning: FUNCTION 'reallocate' declared as FASTCALL with 2 parameters

The Wiki says that FASTCALL functions can only have a single parameter, and sure enough 'reallocate' in alloc.bas has two parameters. This doesn't seem to affect anything in my program, but is this a problem? I note that in the previous build the function was the same, but the warning wasn't generated. :-D

Yes, that's ok.
This is because if you're using -Z the compiler ALLOCates 21*8 = 168 bytes for UDG in the heap, and updates system variable UDG (23675) to point to that address. If you don't do this, you can surely use POKE USR "a", ... to create UDG (the legacy way), but this can corrupt the heap (which now also maps into that memory space).

[LTee]

Cool, thanks for the reply. All systems are GO, then! :-)