8 bit os_f handles

[Richard van der Hoff]

Just to add my 2d worth...

In message <200003301048.LAA15742 at msslsd.mssl.ucl.ac.uk>
          Daniel Ellis <dre at mssl.ucl.ac.uk> wrote:

> 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.

Exactly.  So  changing os_f to 32 bits doesn't help here either.

>  Delaying the introduction of 32-bit file handles makes it more likely
> that such problems will exist for longer.

That's not relevant to this discussion (which is about how to fix the os_f
problem, not when or whether to).

> 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.

... provided all programmers who use OSLib actually recombile their entire
code base and (and this is the part that really bites) third-party
modules. Forcing them to do so is not only unreasonable (since it may be
impossible) but also against the ethos of OSLib, as has been pointed out
here many times.


> > > 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?

Yes.  The fact it's unlikely isn't good enough.  I want a cast-iron
guarantee.


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

But altering the header file can break code in such a way that there is no
way to fix it.  At least if you have to change to os_w, and you manage to
get it wrong, it is fixable.

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

os_w isn't defined yet, so I'm not sure how you intend to use a #define
to change its meaning, and I'm not sure that #defines to change the
meaning of osfind belongs in OSLib itself.  Presumably, though, it would
be possible to add this functionality (specifically, a set of #defines
which make old 8-bit os_f code call the new 32-bit calls) to the
SupportLib.  But really, the code ought to get fixed properly rather than
using kludgy wrappers.

> 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.

Provided you have the source to the code.  I say again: third-party
libraries.

> >    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?

That's not the point.  It's to do with the promises made by OSLib - not to
change the binary interface.  In any case, the array of file handles was
only an example.

> >    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.

That's an entirely different problem. It was just plain wrong, and could
never have worked.  Hence fixing it couldn't have broken things.

> 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.

Rubbish, the only way to work around it sensibly was to fix drawfile.h
anyway.

> if you insist on no binary changes then you're going to find it very
> hard to implement many bugfixes at all sensibly!

I think Jonathon over-simplified.  Where the library is obviously
incorrect (and the os_f case doesn't count as obvious - it is at least
perfectly usable for the time being) it gets fixed.
 
> >    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...

Huh?



-- 
Richard van der Hoff              | mailto:rav21 at cam.ac.uk
Jesus College, Cambridge, England | http://www.jesus.cam.ac.uk/~rav21
-----------------------------------------------------------------------