Date   : Sat, 14 Oct 2006 16:47:12
From   : John Kortink <kortink@...>
Subject: Bugs in OS 1.20

Two major bugs I've just found in BBC OS 1.20 may be worthy
of attention if you use the ROM filing system, directly or
indirectly (e.g. if you produce ROMs containing ROM filing
system data).

Acorn must have fixed these silently in later OS versions
(at least in the Master they seem to be).

The culprit is a piece of routine at F232 which, after a
file load (tape/rom FS) intends to return the file size
in the OSFILE parameter block. It assumes the file size
is (&CC) (i.e. ?&CC+256*?&CD) and that the parameter block
address is (&C8) (i.e. ?&C8+256*?&C9).

Bug #1 : &CC/CD are not updated UNLESS the file has loaded
under *OPT 1 2 (i.e. verbosely).

Bug #2 : a *RUN does not do an OSFILE, but jumps straight
into the 'file load' routine without setting up a parameter
block, nor, therefore, its address in (&C8) !

Result 1 : OSFILE returns an incorrect file size (whatever
was in &CC/CD /before/ the file loaded) if not done under
*OPT 1 2.

Result 2 : *RUNning a file randomly corrupts four contiguous
bytes in memory, in that the file size (correct or not) is
written to a non-existing parameter block, (&C8)+10 onwards,
i.e. where &C8/C9 are unset, as /before/ the file loaded.

&C8/C9 will be 'wrong' easily, e.g. they may have been used
by previous filing systems (as selected before *ROM).

Conclusion :

a) Never use the file size returned from an OSFILE file load
unless you're certain *OPT 1 2 has been issued.

b) NEVER *RUN a file.

I'm not 100% sure that these apply to the tape filing system
as well, but they probably do, and they certainly apply to
the ROM filing system.

Especially the *RUN problem is a /huge/ bug if you ask me.
Beware !


John Kortink

-- 

Email    : kortink@...         
Homepage : http://www.inter.nl.net/users/J.Kortink

GoMMC, the ultimate BBC B/B+/Master storage system :
http://web.inter.nl.net/users/J.Kortink/home/hardware/gommc