8 bit os_f handles

[Jonathan Coxhead]

   David wrote,

 | I don't know if this has been raised before, but I do not think
 | os_f should be an 8 bit type.

   It was raised, at great length, in the early days of this mailing 
list. 

   The key points were ...

   (1) User code may use |os_f| in structures or arrays, and so 
binary compatibility would be broken by a change to the definition of 
os_f from |byte| to |bits|. For example, if I write

      os_f f;

      ... xosfile_openin ("MyFile", &f) ...

and compile with a byte-wide |os_f|, but then link to a version of 
OSLib that thinks it's a word, I'll overwrite 3 bytes of memory that 
are not mine.

   There was a *very* early version of OSLib that had integer file 
handles (pre-public release, certainly), and I can't remember what 
made me change it. It may have been something as subjective as 
compatibility with font handles, or as critical as the layout of 
Econet transmission blocks. Dunno.

   But in any case, that's what we have now, and we never break 
backwards compatibility. This is a professional-quality product!

   (2) Throughout RISC O S, the code assumes its a byte, so it's not 
going to change.

   (3) If we wanted to change to wide handles, I think we would have 
to do the following:

      - invent a new type for wide handles: say |os_w|.

      - clone functions that use |os_f| with identical ones that use
         |os_w|, leaving the original alone. This would give us lots
         of new functions with names like osfile_open_w(),
         osgbpb_dir_entries_w(), etc.

      - do this for *every* function in *every* SWI file, even those
         ones that nobody seems to use ...

Amusingly, the new functions would accept arguments of type |os_f|, 
because of the way C's integer types promote. So changing to the new 
interface would be pretty easy.

   But it's a lot of work!

   (4) I asked,

 | Could someone fill me in on why this has become an issue? As I
 | recall, the internals of RISC O S are full of places which "just
 | know" that a file handle is a byte---this is why I felt safe doing
 | it in OSLib. Has it really changed?

   No-one answered, so the consensus was to leave it alone, as it was 
lots of work for a net gain of nothing whatsoever.

   Then Rick wrote ...

 | I would have to agree with this though the reason it bothers me is
 | not so much for future proofing (which is a good reason anyway)
 | but I've had cause to have variables holding a font handle which I
 | would sometimes like to have 'special' values. Most notably for
 | telling functions to use the current font or desktop font instead
 | of a specific font. For this I find myself having to declare
 | variables as ints to allow negative numbers to be held.

   That's the C way, isn't it :-) ? (The same applies to characters 
returned from getc().) It's the same as mode numbers (|os_CURRENT_- 
MODE|), font handles (though it isn't used---|font_CURRENT| and 
|font_SYSTEM| are both 0); and file handles are the same.

   So, is there any new discussion arising from that lot?

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