8 bit os_f handles

[Jonathan Coxhead]

   David wrote:


 | >    But the solution isn't to introduce our own bugs into other 
 | > people's code. The solution is to make sure that anyone who 
wants to
 | > use a 32-bit aware FileSwitch knows that they have to use file
 | > handles of type |os_w|.
 | 
 | Ok if you are happy that some time in the near future when 32-bit
 | aware FileSwitch is released, under certain cicumstances various
 | application may start suffering from unsual failures, and users 
will
 | find files are becomming corrupted. Eventually someone will track 
this
 | down to the fact it was built with OSLib and has left in an 8 bit 
os_f
 | using call.

   I wouldn't say I was "happy"---I don't like "long long" file sizes 
or wide characters either---but I'd be less happy with the 
alternative.

   With the assurance that |os_f| is always 8 bits, and |os_w| 32 
bits, at least it's clear from looking at the source code that there 
is a bug in the code: if it uses |os_f|, it's wrong. In a world with 
a 32-bit |os_f|, it's impossible to tell from the source code if the 
bug has been fixed: you need to know what iyt was linked withm as 
well. This is a harder problem.

 | The alternative is not much better as you cant elimitate all the
 | software built with old versions of OSLib out there, but you can 
make
 | sure all existing software still in development (and new ones
 | obviously) can be recompiled, tested and known to be safe.

   This is precisely the point. We can't change code for which the 
source is lost. If the source is available, we should make it 
possible (and as easy as possible) to fix. But we should not *force* 
people to change who may not want to. It would be very rude!

 | > | Please belive me you dont want to have to track down these 
types
 | >  of | problems with your code - you will not have a clue why 
certain
 | >   filing | system code works, others dont, and changing the
 | >  slightest thing  can | alter it.
 | 
 | >    You'll know exactly why---it's because you are using narrow 
 | > handles. You'll be able to fix the problems (e g, using the
 | > technique I mentioned in my last message), and they'll go away. 
No
 | > big deal.
 | 
 | No you wont, you'll get the typical user bug reports; "your program
 | crashes" and RISC OS Ltd will get, "RISC OS 4.x is crap, since
 | installing all my files are corrupted".

   I don't believe this.

   While it's likely that people will say "RISC OS 4.x is crap, since
installing all my files are corrupted" (because they are using an 
|os_f| version of OSLib), I think this can only happen with code they 
do not have sources for: 3rd party apps and libraries. Changing 
|os_f| to 32-bit won't help them *anyway*.

 | What do other people think? There must be more than 4 of us on this
 | list?

   I think you *must* have been a politician in a former life! You 
are losing the technical argument, so you are resorting to 
demagoguery! ... or trying to, at least. :-)

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