PRMs do state os_f should be 32-bits

[Stewart Brodie]

I've copied this here manually from my newsgroup posting.  I had intended to
avoid getting involved in this argument, but the statement I quote does give
the definitive statement of how fileswitch handles must be treated.  I also
understand Jonathan's comments, which are based on the fact that FileSwitch
used to AND all incoming filehandles with 0xFF before looking them up in its
handle tables.  If this dangerous practice inside FileSwitch has not been
removed, then it ought to be.

  --- 

In message <CeGp$MA1Tc74Ewhn at mk-net.demon.co.uk>
          Tony van der Hoff <tony at mk-net.demon.co.uk> wrote:

> Nowhere do the PRMs specify a 32-bit file handle

This is incorrect.  The PRMs *DO* specify that FileSwitch filehandles are to
be treated as 32-bit integers.  Reference: Chapter 44 (Writing a filing
system), section "Interfaces", subsection "FSEntry_Open and
ImageFSEntry_Open", page 2-532, subsubsection "Generic details", quote:

"On entry, R3 contains the handle that FileSwitch will use for the file if
your filing system successfully opens it.  This is a small integer (typically
going downwards from 255), but must be treated as a 32-bit word for future
compatibility."

Whether it is useful to have it tucked away in the section on writing your
own filing systems or not, the fact remains that it has been documented there
since the RISC OS 3.1 PRMs were published (1992, says the copyright message)

  ---

>From that, it follows that any filing system currently written to link
against OSLib is faulty if it uses os_f to represent the value coming into
the FSEntry_Open entry point in R3 (although the fault will not be triggered
unless FileSwitch issues filehandles out of the range 1-255)


-- 
Stewart Brodie, Senior Software Engineer    (Views expressed are my own and
Pace Micro Technology PLC                   not those of my employer)
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom         WWW: http://www.pacemicro.com/