8 bit os_f handles

[John Tytgat]

In message <200003290000.QAA00293 at purple.trimedia.sv.sc.philips.com>
          "Jonathan Coxhead" <jonathan at doves.demon.co.uk> wrote:

>    John wrote,
> 
>  | With all respect Jonathan, but the documented API
>  | talks about filehandles returned in a 32 bit word (register).  So a
>  | filehandle is 32 bit wide.  The fact that it just returns values
>  | betwee 1 - 255 is just a coincidence.
> 
>    I can understand that point of view, and I wish more and more that 
> I'd done it that way from the beginning. But I didn't :-( :-(
> 
>    I could fault your reasoning here---just because a file handle is 
> returned in a register doesn't make it 32 bits wide. How else could 
> it be returned, after all?

Euh easy, something like :

R0 =  b7..b0 filehandle
     b31..b8 0

This kind of documentation is used by the PRM's, e.g. p. 4-150 :

                                            Podule_HardwareAddress
On entry
  R3 = ROM section [...]
On Exit
  R3 = combined hardware address

[...]
Use
  This call returns an expansion card or extension ROM's combined hardware
  address:
    Bits             Meaning
     0-11            base address of CMOS RAM [...]
    12-25            bits 12-25 of base address of expansion card [...]
    26-31            reserved
[...]

> I would rather call it an "ambiguity" in the P R M's.

I do not agree.  There is nowhere an ambiguity that filehandles
might be defined as 8 bit values.  There are no statements nor hints
nor conflicting descriptions in the PRMs that RISC OS filehandles might
be 8 bit values.

> But I admit that history is firmly on your side.
> 
>  | I do *not* care how FileSwitch is internally managing its filehandles
>  | as as a programmer I have to make abstraction from it.
> 
>    I agree with that as well---but you have to make the right 
> abstraction. If you had looked at FileSwitch, and seen how extensive 
> the 8-bittedness of file handles is, you might have more sympathy for 
> my mistake;

Jonathan, I respect you very much and I am grateful for all the work
you've done in OSLib.  You have all my sympathy for your mistake. That's
what I've said before : we all make mistakes; but lets now solve them
before they really bite us.

IMHO you may not be distracted by current implementation of FileSwitch.
The 32 bit filehandles can come via another path : today, somebody can
enhance the sequential file access by intercepting all filehandle related
operations and let this util return >255 value filehandle (e.g. ptr's to
his workspace per open file).  And at that point, all our OSLib based
programs might go down because of his perfectly legal & correct piece
of software.  That's what I want to avoid.

> but I don't suppose you would be any less convinced it 
> was a mistake. I'm pretty much convinced at this point myself! 
> Certainly, I have no evidence that any other published interface 
> would have failed to work if |os_f| had been 32 bits from the 
> beginning.
> 
>  | I just want to
>  | make sure that my programs linked today will work in the future when
>  | there are >255 value filehandles (potentionally it is just being done
>  | by a simple module which hijacks the OS_Find/OS_GBPB/... vectors).
>  | 
>  | >    If the FileSwitch interface becomes 32-bit, the OSlib interface 
>  | > will evolve to keep pace.
>  | 
>  | ...and in the meanwhile all programs linked with today's OSLib
>  | potentionally won't run anymore.  Great.
> 
>    That's not true---they will only fail to run if they get a file 
> handle that is actually >255. This might never happen.

Euh, why "never" ? I see two scenario's where today's OSLib based
programs can fail because of this os_f 8 bit issue :

1. A new version of RISC OS with upgraded FileSwitch returning >255
   value filehandles.  All OSLib based programs we link today might
   break on that OS.  That's something I want to avoid to doing the
   necessary fixes today.  It is dummer to hear that your programs
   don't run on RISC OS x because you were using a library incorrectly
   making assumptions about something.

2. Someone writes a module enhancing sequential file access and
   remap's FileSwitch handles by its own handles which have values
   bigger than 255.

You might argue that scenario 1 will never happen (only the future
will tell us) but scenario 2 is a realistic one and can happen any
moment.

>    And in any case, there's nothing we can do about it. That code is 
> already out there, in binary form,

If we act now by changing os_f to a 32 bit wide value, all programmers
can recompile their programs now, retest it and spread it before one of
the two above mentioned scenario's happen.

> and possibly the sources have been lost.

If the sources are lost, then I don't see any point in relinking
with a new OSLib.  I suppose development of that product is dead.
Do we really have to consider this case ?

> We can't force people to recompile their code, any more than we 
> can force them to change |os_f| to |os_w|.

Of course we can not force people as they are not forced to use
new OSLib versions.  But we can gently say : "If you want
to use this version, note that os_f ... etc.".

> The question is simply 
> whether we maintain a fixed relationship between source & object (as 
> I advocate), or if we try to fix bugs by introducing new ones---
> because that's what changing |os_f| to 32-bits would do.

There shouldn't be any new bugs introduced when a full recompile
happens and make this as a requirement for the next version of
OSLib please.

And programs relying on the fact that os_f is 8 bit and always will
be 8 bit and go wrong when os_f gets a size bigger than 8 bit or are
used to story anything else than RISC OS filehandles, are buggy and
should be fixed ASAP.

>  | Everybody makes mistakes.  Let's move forward and try to correct
>  | these.
> 
>    Absolutely---but not by breaking code.

But my program is already broken ! My OSLib based program is not garanteed
to work when OS_Find returns a >255 value !

>    Here's an argument based even more firmly in logic: the 
> compatibility-breakers say, "you can get the benefits of wide handles 
> by recompiling, and if you can't recompile, your code (which 
> previously was perfectly good) is now broken;          ^^^^^
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Not true ! All our OSLib based programs today can go wrong a system
with >255 value filehandles !

> and we don't care". The 
> stability-advocates say, *if* you can recompile, **then you can 
> change the source to get the new effect**. But we *also* point out 
> that your old binaries will still work (unless they encounter 
> circumstances they were not written to cope with---that's a problem 
> no-one can solve, anyway). They will not under the compatibility-
> broken scheme.
> 
>    And note that the brokenness in the first case---overwriting 
> memory you don't own---is more severe than in the second.

But my OSLib based program is now already broken !

>  | > [...] compatibility: it's a professional ideal.
>  | 
>  | It also gives a professional touch when your programs keep on running
>  | on a new OS without having to sputter "hold on, I need to recompile"
>  | and send out hundreds update copies...
> 
>    Well, quite. You seem to have changed sides in the discussion here!

I think there are two discussions going on and we/you're mixing them :

  1. Are RISC OS filehandles 8 bit or 32 bit ?

     My argument in above quoted paragraph concerned this discussion.
     I want to make sure that my OSLib based programs are garanteed
     to work when >255 value filehandles are being used.  I want to
     act proactive on this issue and have a solution.

  2. How are we going to address this ? By introducing os_w or
     upgrading os_f to 32 bit value ?

     This discussion seems to turn around the question of relinking is
     enough or that a recompile based on Makefile is ok or full recompile
     is needed, wanted, realistic, etc. My statement in above
     mentioned paragraph was not meant to be used in this discussion ;-).
     Whatever option is taken for discussion 2, an action of the
     programmer is needed (relink/recompile/whater) and that's something
     I want to do ASAP.
     
     However I would advocate to go for the short pain and inform in the
     next release of OSLib that this change has happened and that there
     are consequences of using this release (with detailed description).
     And in that new version of OSLib there is no place for an 8 bit
     filehandle.  Sorry but such a thing does not exist in RISC OS
     PRM's.

>  | Let's add a big warning to the next OSLib version : using this version
>  | requires a full recompile and note that filehandles (os_f) are now 32
>  | bit wide instead of 8 bit.
> 
>    How about this instead: a big warning that says:
> 
>       A future version of FileSwitch may return handles >255. Any

Not only future versions of FileSwitch.  Even a third party module
can cause this.

>       code that uses |os_f| will then behave unpredictably. To
>       safeguard against this possibility, the new handle type |os_w|
>       should be used instead. All existing FileSwitch calls that use
>       |os_f| have been cloned with 32-bit versions whose name is the
>       same as the 8-bit version with |_w| appended.
> 
>    This is no worse than the change to |long long| for file sizes, or 
> to |wchar_t| for character data, and it exactly parallels them, both 
> in its reason for being necessary (extended interface), and its 
> resolution (extra calls for the new types).
> 
>    Now, how about font handles ... do we also need |font_w|? 
> Including font_find_font_w(), font_lose_font_w(), font_paint_w(), 
> etc, etc, etc??

Upgrade to 32 bits and no _w please... <ducks> :-)

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven