8 bit os_f handles

[Daniel Ellis]

Jonathan Coxhead writes:
 >    David wrote,
 > 
 >  | This is users we are talking about. They will not know the
 >  | relationship between 32bit handles and OSLib problems. They will 
 > look
 >  | at the last major change to their system and summise it is the 
 > fault
 >  | of the OS that files are becomming corrupted. They will not suspect
 >  | program XYZ which they have had for years is causing the problem.
 > 
 >    No library change can help them. In fact, it is *not* users we are 
 > talking about, it is programmers. Only programmers compile code. If 
 > they compile code, they can easily change it to use |os_w|. That's 
 > all.

You can't recompile a Module that you might like to use with your
software. If that module incorrectly addumes 8-bit filehandles then
there's nothing you can do about it.  Delaying the introduction of
32-bit file handles makes it more likely that such problems will exist
for longer.

It is far easier, quicker and less error prone to recompile code than
it is to search and replace for any code that uses 8-bit filehandling
calls.

 >  | It comes down to two choices:-
 >  | 
 >  | 1) change os_f to 32bits
 >  | 
 >  | Advantages    : Fixes OSLib to bring it into line with the API.
 >  | Disadvantages : Incorrect use of the library may fail
 > 
 >    Changes the definition of "incorrect use of the library" in an 
 > incompatible way.
 > 
 >    Causes previously correct code to be broken.

You mean, causes previous binaries which might get linked with OSLib
to cause a memory overwrite in the unlikely case that a pointer they
pass to an 8-bit filehandle function has data in the rest of the
32-bits?

 >  |                 Extra work to change existing functions
 > 
 >    True, but if you are going to recompile something anyway, you can 
 > easily make this change.

This introduces more chance for errors - it is far easier to alter a
header file than do a search and replace and make sure each change was
correct!

 >    And so it is---no disagreement there. It is simply a question of 
 > offering a choice, instead of forcing people to do something they may 
 > not wish to do.

So the alternative is to have different compilation environments
i.e. defines which change the meaning of os_w and osfind which will
involve editing the header files in which they reside, which will mean
thet any files which include them will have to be recompiled anyway.

 >    Imagine someone has a complicated programme that would break if 
 > file handles were 32 bits (maybe it's memory-limited, and has an 
 > array of file handles in it somewhere), and they don't want to get 
 > the new FileSwitch. They should be able to continue using OSLib to 
 > develop their programme. They would curse if we broke their programme 
 > for them, and for nothing (the FileSwitch they have is an 8-bit one, 
 > remember).

Do you really think that anyone has an array of filehandles so large
that this problem would arise?  They're far more likely to curse for
the change not being made.

The fileswitch they have is 8-bit, but they may load extensions which
make use of more than 8-bit.

 >    I know your response: "we don't care about them, we'll make them 
 > upgrade". But where do you draw the line? Which (binary) changes are 
 > acceptable, and which are not? It's conceptually much simpler to just 
 > say, "*no* binary changes are acceptable", and live with that.

If you are going to say *no* binary changes are acceptable then you'll
have to live with attrocious errors like the size of the scaling
factor in the drawfile sructure being wrong.  It took me ages to track
that one down - I'm pretty sure I submitted a bug report but don't
recall whether it was acted upon.  There was a quantity which should
have been a double but was defined as a float in the structure (or
vice versa, my memory fails me slightly).

Now you could argue that everyone who used that structure now is
working around it (somehow, I can't imagine how though!) and it must
be left in for the sake of binary compatibility.

I admit that there is a difference though between a structure (no
associated library binary code) and a function - but the point still
stands: if you insist on no binary changes then you're going to find
it very hard to implement many bugfixes at all sensibly!

 >    You don't care if *you* break *their* programme---but what if the 
 > tables are turned, and they break yours? You hate Microsoft when they 
 > do it: why do you think people won't hate you, if you play the same 
 > trick on them?

Be very careful what you say!  What so you people will be saying if
they find that using 8-bit filehandles breaks there code...

cheers,

-- 
Dan Ellis
Software Engineer
Climate Physics Group
Mulard Space Science Laboratory