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