8 bit os_f handles

[Jonathan Coxhead]

   David wrote,

 | On Fri 31 Mar, Daniel Ellis wrote:
 | > I must say you have a point here: one solution potentially causes
 | > writes to non-existent file handles, the other causes obscure 
memory
 | > corruption.  I think there's no question that the latter is more
 | > dangerous.  
 | 
 | No the former is far more dangerous!
 | 
 | Consider program A opens file handle 10, program B opens fie handle
 | 266 (256+10), but uses OSLib's xosfind call so the file handle
 | truncated to 8 bits when written back through the os_f pointer. Now
 | program B writes to program A's file. 

   Your conclusion does not follow from this, at all! Rather, it is 
as I said---the *former* is more dangerous. The effects you describe 
are limited to corrupting files. If memory is corrupted, *anything* 
can happen---including corrupting files, and also anything else.

   (If you need concrete evidence, consider an array |os_f h [4];|. 
Suppose |h [1], h [2], h [3]| contain valid handles which the 
application is using. It calls |osfind (..., &h [0])| to fill in
|h [0]|, but because the OSLib version is newer, |h [1], h [2],
h [3]| are corrupted to arbitrary values too. The next use of |h [1]| 
will corrupt the contents of whichever file is open with that handle.)

 | Invalid assumtions such as os_f in something in as widespread use 
as
 | OSLib really spells the deathnell of the current RISC OS API. It 
will
 | not be possible to introduce key extensions to the filing system 
for
 | general users because of the risk of corruption from 3rd party
 | programs linked with OSLib.

   "The deathknell of the current RISC OS API"?? Hyperbole much!!

   If you limited yourself to technical arguments, and attempted to 
understand the answers, you would be a much more satisfying person to 
debate with.

 | New features will have to be delayed until the new 32bit API is
 | finalised, when broken code will have to be fixed as part of the
 | porting process, and existing applications will sit behind a
 | compatibility layer. This is means a considerable delay.

   Quite the reverse. If we introduce |os_w| soon, anyone who wishes 
to may upgrade to it (note---their code will be written, and can be 
tested, long before any actual 32-bit FileSwitch is seen). So no bugs 
will be seen.

   If we changed to a 32-bit |os_f|, the same would apply, except 
that (a) people would be *forced* to upgrade when they next compiled, 
and (b) horrible bugs could be introduced into their code as a 
consequence.

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