🚀 go-pugleaf

In article <1992Aug19.200810.1@vxdesy.desy.de> burke@vxdesy.desy.de writes:

>  The PRM seems a bit inconsistent on the subject of interrupts in SWIs.

Unfortunately the RISC OS 2 PRM is out of date - it describes what the
situation was under Arthur. In RISC OS 2 interrupts are usually enabled when
your SWI entry code in your module is called. In fact interrupts are in
whatever state they were in when the SWI was issued, which means they are
almost always enabled. This also means that enabling them if they were
disabled may be dangerous, since IRQs were disabled for a reason by the code
that called your SWI. This is fairly unusual though - how much code have you
written that calls SWIs with IRQs disabled?

>  Now to the thorny subject of errors.

I'm not going to answer what you asked, but make a different point instead.
Please remember that *ALL* SWIs are capable of returning V set R0 -> error,
so whenever you call *ANY* SWI (including OS_WriteC and the like) you should
check for a V set error return.

There are a variety of ways you can get an error from a SWI that you don't
expect. If it's not an OS SWI, just RMKill the module :-). OS SWIs may be
intercepted by some dodgy software, either through a vector or illegally by
patching the SWI table; alternatively you may be spooling or using the
printer drivers. A good case in point is Sound_InstallVoice (PRM page 1593).
This says "If an error occurs, this SWI does not set V in the usual manner.
Instead R1 is zero on exit, and R0 points directly to a null-terminated
string." While this is strictly true, it is misleading as it implies you
don't need to check for V set error return at all. This is false - if you
*RMKill the SoundChannels module you get V set R0 points to a SWI not known
error block. So you need to check V set first, and then check for the
unusual way this SWI returns errors.

Owen.

The views expressed are my own and are not necessarily those of Acorn.