Is this the oldest bug in RISC OS?

This would seem to work:

DIMq%255:!q%=0

FOR?q%=1TO5:PRINT?q%:NEXT

That seems quite straightforward, if eccentric. However…

!q%=-1

FOR?q%=1TO5:PRINT?q%:NEXT

Ha!

I bumped into this while modifying FOR – the bug is that although FOR is totally happy with a byte-sized index variable, NEXT has never heard of them, and treats it as a word. Oops.

How can I be sure this is the oldest bug in RISC OS? Because even the BBC Micro’s BASIC did this too. So that’s a bug created at least six years before Arthur.

It can be fixed (I used b31 of the index address to indicate its byteness) but it would be better to error the syntax in FOR, which is only a single additional instruction.

Is the index address the address of the control loop variable, so q% in the above example (as opposed to address-of-q%’s-data in the usual FOR q%=…)

Probably best not to use bit 31, that prevents the index address being in memory above 2G. As the address has to be word aligned, best to use bit 0 or bit 1 which will be defined to normally be zero. While BASIC’s heap being 2G in size is somewhat extreme, it is common to put the heap somewhere in memory other than at TOP*, and there’s no reason that that ‘somewhere else’ can’t be above 2G.

*It’s the other way around, but ROM applications written in BASIC do some jiggery-pokery to do PAGE=romaddress:LOMEM=normalPAGE (ie &8F00 32-bit BASIC).

Is the index address the address of the control loop variable

No, it’s the address that will be incremented by NEXT, so you’re quite right about very high dynamic areas. In which case a different NEXT token would be required on the stack (there’s already two, for floats and ints).

As the address has to be word aligned

No, doesn’t. It’s the address that gets incremented, and even FOR!a% is happy with unaligned words, so unaligned bytes is a given.

As I said though, it has never worked in an Acorn Basic, so it would be better for FOR to fault it than for some versions to work and others silently do much more looping and corrupting of other bytes. Uggh.

!q% = 256 produces a differently odd output :)

Indeed. And on a Beeb too. Doctor, can I borrow your blue box?