8 bit os_f handles

[David J. Ruck]

On Sat 25 Mar, Jonathan Coxhead wrote:
>    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.

Arrrrrh! Any changes to library should result in a complete rebuild of
any projects that use it - anything else is extreamly dangerous. All
makefiles should have a dependancy on the both the headers for objects
and the library for the executable, to take care of this automatically.

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

But this is a statically linked library so does not require you to keep
binary interface compatibility - only synamic linked libraries like the
Shared C library need to do this. Putting this limitation on yourself
artifically can only constrain the development of the library.

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

That is not a valid assumption, much of RISC OS is going to be re-written
in the near future. While you cannot guess all the implications of this
now, simple things such as ensuring the current API is implemented without
any invalid assuptions will mean code has a much better change of continuing
to work.

>    (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!

And not necessary. Just make os_f of type bits, and put in the replace not
for the next version that code needs to be recompiled. The implications of
doing this are less for file handles as they are transient objects and
should not be stored on disc as part of a structure, whos length may now
have 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.

A net gain of not breaking the vast amount of software that is linked with
OS_Lib on a the future version of RISC OS?

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

On a slighly different note; everyone should be thinking ARM 32 bit mode
conversion from now on. Its going to be a vast amount of work for every RISC
OS developer, and one of the things we need to rely on is that essential
libraries such as OSLib, will be both 32bit ready and cater for all existing
API's and new extensions. Removing potential problems such as os_f now, will
mean a lot less work over the cirtical times to come.

Cheers
---Dave

-- 
______________________________________________________________________

  David J. Ruck     Phone: 07974 108301     Email: druck at freeuk.com
______________________________________________________________________