8 bit os_f handles

Daniel Ellis dre at mssl.ucl.ac.uk
Thu Mar 30 12:01:21 BST 2000


 >    It is easy to construct a scenario where a module (for which you 
 > have no source) asks for a file handle, and your code writes an 
 > |os_f| to that memory location. The module knows that |os_f| is 8 
 > bits, and has only given you a |char *| to write through. Your 
 > programme thinks |os_f| is 32 bits, and trashes the module's 
 > workspace.
 > 
 >    And it's worse than that---the module interface documentation 
 > might have been written using OSLib type names. It could easily say 
 > that the pointer is of type |os_f *|. You write an |os_f| through the 
 > pointer. Bang!! Whose bug is this? It's not in the module---it 
 > described everything correctly, as at the time it was written. It's 
 > not in your programme---how could it know that the module was written 
 > before March 2000 (or whenever)?

OK.  Lets just reflect upon this then.  What you are implying is that
for the sake of modules written using OSLib, _NO_ file handles shall
ever be greater than 8-bits large, and by implication this should
become part of the RISC OS documentation that OS_Find returns 8-bit
file handles.  I can't see any other way around your problem.

Do you agree?

Maybe then in the new OS we can have OS_FindW which can return long
file handles (or something equivalent like different ranges of args,
or a flag set somewhere).  The important point being that the OS
should _never_ return filehandles with more than 8-bits of
significance unless the caller has specifically allowed for it.

Therefore anyone who wishes to take advantage of the fact that there
are OS procedures for using more that 8-bit filehandles should
specifically make the new calls, and by implication, all programmers
should be told of this when/if such a new product arises.  I guess
this isn't such a big problem - a bit like the issue of font blending maybe.

In fact, maybe it would be a good idea to have to request wide
filehandles anyway?

-- 
Dan Ellis
Software Engineer
Climate Physics Group
Mulard Space Science Laboratory



More information about the oslib-user mailing list