Trivia: What will this program do?

[regregex]

Go on, guess!

Code: Select all

0GOTOFNg(0)
1DEFFNg(?-1)PRINT"Hello World!":=0

[BeebInC]

Dunno just keep printing hello world?

Haven't really used beeb basic in years

[Arcadian]

Is it the entire vertical scrolling routine from Firetrack?

[sorvad]

You've got me to byte

Yes, on the face of it just prints Hello World repeatadly, but why the other stuff ?

?-1,

OK this is going to return the contents of location 65535, Mmmmm.... if Beeb BASIC treats this as an integer and not a byte. Location &FFFF is the low order byte of the 6502 hard reset boot vector if memory serves me right. But how does passing 0 fit into it all.

Is all the other stuff a red herring just for a giggle ?

At the end of the day the code just seems to print hello world but I've got to suspect there's something else to it ?

[SarahWalker]

FNg returns 0. Hence GOTOFNg(0) = GOTO 0. Not sure about the ?-1 though - probably a red herring.

[b_b_c_m_i_c_r_o_2]

[sorvad]

On your beeb set up it seems to be a self corrupting program ?

Doesn't do that on mine, program remains intact and when run it repeatedly prints "Hello World!".

My system is a Master 128 though.

[regregex]

You've got me to byte

Yes, on the face of it just prints Hello World repeatadly, but why the other stuff ?

The Hello World is only there because otherwise the program does nothing, which instantly makes people suspicious

?-1,

OK this is going to return the contents of location 65535,

...It's in the function definition, so it's a formal parameter, and they're automatically made LOCAL...

Mmmmm.... if Beeb BASIC treats this as an integer and not a byte. Location &FFFF is the low order byte of the 6502 hard reset boot vector if memory serves me right. But how does passing 0 fit into it all.

?-1 was chosen to add mystery, and because in OS 1.2 it contains a fortunate value for our purposes.

Once evaluated, the value of ?-1 is an integer like any other. The BASIC stack can only contain integers and strings. So when ?-1 is made LOCAL and then restored, four bytes of memory are overwritten. Looking at the code I suspect the BASIC designers wanted to highlight this by restoring to an arbitrary address -- in this case the byte before the FN call.

This was probably fixed in BASIC IV, hence the program behaves as expected on the Master.

We can do worse...

Code: Select all

0PROCg(0)
1DEFPROCg(?-1)ENDPROC

[sorvad]

Thanks for the interlude Beardo, really did throw me as I only use a Master and electron. So nothing untoward happened. (Actually didn't test on Electron but suspect it was fixed for that machine also).

[sorvad]

Update : Just tested on ElectrEm, does corrupt the code as it does on the Beeb.

[SarahWalker]

Yep, corrupts on the Electron. I can only make it corrupt on the BBC by making a typo as b_b_c_m_i_c_r_o_2 did above (line 1, not line 10). Type as originally given and it works fine.

[sorvad]

Tom,

It was line 1 in the original . Well unless my eyes are going funny

[sorvad]

Oh hang on, sorry just reread the thread. You mean that it will only corrupt if you enter 10 not 1, sorry my mistake Using BeebEm it corrupts for me though;

[SarahWalker]

So it does! Could have sworn it ran correctly before for me.

[b_b_c_m_i_c_r_o_2]

Tried it with ?&70 instead of ?-1




<Annoying Wesley Crusher Mode>

Can we sum up what is happenning behind the scenes in the BASIC interpreter?

I understand that the stack can get upset but how is the program area getting trashed?

</wesley>

[/img]

[regregex]

When a ?N value is made LOCAL, the address (N) is saved on the 6502 stack, instead of at location &37..38 as the !N operator does. The junk in &37..38 is then pushed on the BASIC stack as the restore address. Sadly for us the junk happens to be the address of the PROC/FN name, less two, or of the last variable name seen since then, less one.

So when PROCg(0) is called, the formal parameters are LOCALised. ?-1 is read (its value is &DC, the token for DATA) and stored on the BASIC stack followed by the bogus address. Then ?-1 is assigned the argument, 0 (which does no good as the MOS is read-only memory.)

Then the computer meets ENDPROC, so all LOCAL variables are restored. BASIC simplistically pulls address-value pairs off its stack. The byte has been converted to an integer and the address is wrong, so the DATA token and three zeroes are pasted 'back' over the PROCg call. (The real address is of course not restored, and the address is left on the 6502 stack.)

If there's a space after the line number we are spared the worst, the line is simply commented out. If not, the first byte overwrites the length byte of line 0 and the program is destroyed.

If the ? expression is in a LOCAL statement, and contains a non-resident variable (e.g. LOCAL ?bb%) then the worst that will happen is the ? expression corrupts itself.

----------

Tracing the BASIC ROM as it runs this program:

The code at B1A1..B1D5 saves the address after the PROC call, less two, in locations 37,38. It then calls 955B with Y=2 to find the length of the procedure name. If any other variable names are scanned then presumably these will leave a different address in 37.

Sometime later, the formal parameters are made LOCAL. (Many thanks to Richard Gellman for the BeebEm debugger.)

Code: Select all

B259..76	Restores X, 19..B. Pushes 2A..C (address and data type) on 6502 stack
 B30D..18	Choose ! or ?
  B32C..51	Fetch byte from address in &2A,2B.  Clear Y
  AEEA..F6	Store 8/16-bit value in 2A..D (IWA), data type=&40 (integer)
 B31B..1C	Push data type on 6502 stack
  BD90..99	Test data type, decrement stack pointer for integer
   BE2E..40	Store stack pointer, test for No room
  BD9C..B1	Store contents of IWA on stack
 B320..26	Test data type, load X=&37
  AF56..68	Load dword at 0,X into IWA, data type=&40
 B329		Jump
 BD94..99	Decrement stack pointer for integer
  BE2E..40	Store stack pointer, test for No Room
 BD9C..B1	Store contents of IWA on stack
B279..		Scan next DEF PROC argument...

Program 1:

Code: Select all

>LIST
   10 aa%=&12:cc%=&34
   20 DIM bb% 4:!bb%=&56789ABC
   30 B%=bb%
   40 PROCgg(1,2)
   50 PRINT ~aa%,~bb%,~cc%,~B%,~?B%
   60 END
   70 DEF PROCgg(aa%,?B%)
   80 PRINT "Test"
   90 ENDPROC
>RUN
Test
        12      17AE        34      17AE         2
>

Line 70                 Result
DEF PROCgg(aa%,?B%)     RUNs, !B% overwritten
DEF PROCgg(A%,?B%)      RUNs, !B% overwritten
DEF PROCgg(A%,?bb%)     DEF PROCgg(A%,<corrupted>)
DEF PROCgg(aa%,?bb%)    DEF PROCgg(aa%,<corrupted>)
DEF PROCgg(?bb%,cc%)    DEF PROCgg(<corrupted>,cc%)
DEF PROCgg(?B%,cc%)     PROCgg call corrupted
DEF PROCgg(?B%)         PROCgg call corrupted

----------
Program 2:

Code: Select all

>LIST
   10 DIM bb% 4
   20 !bb%=&56789ABC
   30 B%=bb%
   40 PROCgg
   50 PRINT ~!bb%
   60 END
   70 DEF PROCgg
   80 LOCAL ?B%
   90 PRINT "Test"
  100 ?bb%=1
  110 ENDPROC
>RUN
Test
  56789A01
>

Line 80                 Result
LOCAL ?B%               RUNs, ?B% overwritten
LOCAL A%,?B%             "     "       "
LOCAL aa%,?B%            "     "       "
LOCAL ?B%,C%             "     "       "
LOCAL ?B%,cc%            "     "       "
LOCAL A%,?bb%           LOCAL A%,<corrupted>
LOCAL aa%,?bb%          LOCAL aa%,<corrupted>
LOCAL ?bb%              LOCAL <corrupted>
LOCAL ?bb%,C%           LOCAL <corrupted>,C%
LOCAL ?bb%,cc%          LOCAL <corrupted>,cc%

[sorvad]

Cheers Beardo for that full explanation

[b_b_c_m_i_c_r_o_2]

cool, cheers Now I need to find a forum for when people pull out C++ conundrums of this vein at job interviews along the lines of explains what wrong with this simple statement, etc !

[sorvad]

Oh, been there ! Once went to an interview for assembly programmer/ designer for Atmel embedded processors. This was listed as core to the job with C as a desirable (at the time hadn't touched C for 10years) and then I was faced with a full test on C and nothing about the Atmel ! Interviews can be weird !

[regregex]

You can also get up to some mischief with this trick, to execute code that would appear 'unreachable' if you look at the listing. It's almost obvious and not very satisfying.

Code: Select all

   10A%=ASC("1")
   20PROCa:PROCb(0)
   30GOTO20
   40DEFPROCa:ENDPROC
   50DEFPROCb(?&404):ENDPROC
   60DEFPROCa1:REPEATPRINT"Lame duck":UNTIL0:ENDPROC

(Where &404 is the location of the resident variable A%.)
You can also lock yourself in, i.e. after you destroy the line pointer you still have control and can do a limited number of things (but not RESTORE or calling any other functions for the first time.) When you exit, the user is left with a Bad program and cannot see your self-modifications or RUN the program again.

[regregex]

Thread resurrection!

Code: Select all

10 FOR I% = 2147483646 TO 2147483647
20 PRINT "Listen very carefully, I shall say this only twice"
30 NEXT

[BeebMaster]

I haven't typed it in yet, but I'm going to guess that it interprets the first number as the most minusest minus number possible and the second number as the most plussest plus number possible and therefore does the loop 20 trillion times instead of 2.

[BeebMaster]

Typed it into Station 128 getting on for an hour ago.

Still going!

[BeebMaster]

Still going!

[regregex]

It's an infinite loop. After the second pass the stepping addition in a FOR loop silently overflows to -2147483648, and so the loop never exits, as there's no integer greater than 2147483647.
BASIC's got lots of bugs with the minimum value actually -- least of all integers, indeed.
--Greg

[BeebMaster]

Well, I was half-right, that's quite good for me!

Still going by the way - although that's to be expected I suppose!

[jgharston]

BASIC's got lots of bugs with the minimum value actually -- least of all integers, indeed.

I don't consider integers rolling round a bug, but a useful feature. It means you can do things like !word=!word+something without worrying that it's going to bomb out just because !word happened to previously contain &7FFFFFFF and something happened to be 2.

Overall, BBC BASIC has suprisingly few bugs from BASIC II onwards.

[BeebMaster]

Still going!

[1024MAK]

Roll up! Roll up!
Place your bets!
What will be cause of BeebMaster's Station 128 to "end" the running of this little program?
> The program ending?
> A power blip? (Had a "nice" power blip at work last night, PC, printer, lights everything on the "domestic" mains died for about 3 seconds. Lucky that I was only "browsing" at the time...)
> Station 128 dieing silently?
> Station 128 going up in smoke?
> BeebMaster getting bored and switching off or resetting Station 128?
> The world as we know it ending?
Don't leave it too late, if you bet is placed after the end of the world there will be no refunds

[paulv]

If it doesn't go up in smoke, it'll be Beebmaster getting bored and turning it off...

After all, he can only cope with things for 25 minutes at a time... Lightweight

Paul