8 bit os_f handles

[Jonathan Coxhead]

   Daniel wrote,

 | 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

   No, I'm not saying that at all ... I'm saying that *|os_f|* should 
only ever be 8 bits large. That's a very different thing!

   Here's another argument in favour of stability. (This discussion 
is interesting, in that it has made me come up with lots of reasons 
for compatibility which I hadn't thought of before ...)

   It's a question of what a name means. We have a name for an 8-bit 
handle: |os_f|. That's a certain "thing". We want a 32-bit handle: 
that's a *new* "thing", so it needs a new name. This promotes 
accurate communication between humans, as well as between application 
and library.

 | 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.

   I think that a case could be made for that point of view, but I 
don't subscribe to it myself. The difference is that the "official"
A P I is described in terms of assembly language. In producing a C 
binding, I had to make some extra decisions, and one of those was 
that |os_f| was 8 bits (which implies the real problem, that |os_f *| 
only points at a byte).

   So I'm not expecting RISC O S Ltd to clone the calls any time 
soon. They will be able to say, justifiably, that they have a whole 
register for output, and they can use it. We can't do that, because 
the C code that we support has incorporated the 8-bit assumption in 
writes to memory through |os_f *| pointers.

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

   Even if you only save 8 bits of file handle in your assembler 
client of FileSwitch, your code is not going to corrupt memory, 
though it's going to fail with wide handles. The situation is the 
same with C code that continues to use |os_f| with wide handles: it 
won't work if it actually gets a wide handle, but it won't corrupt 
memory either. In both cases, the fault can only be fixed by 
recompiling/assembling.

        /|
 o o o (_|/
        /|
       (_/