GOTO -1

[hellomike]

Hi,

Yes, indeed, after days of coding I ended up with this 'program'

Code: Select all

	GOTO -1

Actually found that this 'program' crashes BB4W 6.12a. No error message, just dies.

SLIDE 1.07a also stops silently but unlike BB4W, the editor stays put.

Of course this would never occur in modern (>1988) programming since no one is using GOTO's. So I can't be bothered but I thought Richard would like to be aware of it. It could give unexpected behavior in old large sources that uses calculated GOTO's, like: GOTO A.

I stumbled on it after copying the Sinclair ZX81 BASIC source verbatim from: http://rosettacode.org/wiki/Chaos_game# ... ZX81_BASIC

Regards,

Mike

[RichardRussell]

I thought Richard would like to be aware of it.

I am. You may be surprised to learn that it happens 'by design'.

In the 'old days', before the introduction of labels in BB4W and BBCSDL, the only valid destination of a GOTO, GOSUB or RESTORE was a line number, which must be in the range 1-65535. So before labels existed 'GOTO -1' was equivalent to 'GOTO 65535' and wouldn't crash. But with labels any value is accepted and if outside the range 1-65535 is assumed to be the address of a label in your program.

If you know about such things, you will be aware that 'address validation', that is determining whether an address corresponds to 'real' (accessible) memory or not, isn't straightforward. Raymond Chen, the Microsoft guru and blogger, takes the view that the easiest and safest way to deal with an invalid address is to allow your program to crash, so I do!

One of the advantages of BBCSDL over BB4W is that the IDE and the user's BASIC program(s) run in separate processes, so are isolated from one another by the OS. However catastrophically a BASIC program crashes, it should not be possible for it to bring down the IDE. Of course crashing may not be the best thing to do from the point of view of debugging - it can make finding the cause of the fault more difficult.

I could treat -1 as a special case, since it's highly unlikely to be the address of a label, but currently my interpreters accept all values. If you use GOTOs in your programs you deserve everything you get...

[hellomike]

If you use GOTOs in your programs you deserve everything you get...

Fair enough Richard. I feel I do have not to emphasize it but to be absolutely clear on this: it was NOT a complaint.

Regards,

Mike

[Soruk]

For the purpose of comparison, Matrix Brandy allows GOTO 0 (and a program line number of 0). Indeed the range 0..65279 is valid.

GOTO -1 (and any negative number, or a variable) gives "Syntax error". GOTO requires a constant, you cannot give it a variable.

[p_m21987]

I'm surprised to hear that, Soruk. I remember using GOTO with a variable in a program I wrote for the BBC Micro. Did BASIC on the ARM/Archimedes allow GOTO with variables?

[RichardRussell]

GOTO requires a constant, you cannot give it a variable.

Are you sure? That seems unlikely given that every other implementation of BBC BASIC I am aware of does allow a variable to be used as the destination of a GOTO. It certainly works in the original 6502 BASIC and in Acorn's ARM BASIC (which Brandy is generally closely compatible with). It also works in all my BASICs: Z80, 8086, Windows and SDL 2.0 (including 64-bit and ARM editions).

[KenDown]

10 x%=20
20 PRINT"Test""
30 GOTO x%

This works fine *provided* you have line numbers. If you do not - which is the default with BB4W - you get a "No such line no." error. I should imagine that GOTO 20 would produce the same error.

[Soruk]

10 x%=20
20 PRINT"Test""
30 GOTO x%

This works fine *provided* you have line numbers. If you do not - which is the default with BB4W - you get a "No such line no." error. I should imagine that GOTO 20 would produce the same error.

It looks like we've unearthed another Brandy bug!

Code: Select all

Matrix Brandy BASIC VI version 1.22.1 (Linux) 20 Sep 2019

Starting with 524288 bytes free

>10 x%=20
>20 PRINT "Test"
>30 GOTO x%
>RUN
Test

Syntax error at line 30
>_

Edit: It turns out expressions and variables were allowed, if wrapped in parentheses. I've removed this restriction for variables (still required for expressions that begin with a number), and matches behaviour for BASIC IV, V and VI.