8 bit os_f handles

[Daniel Ellis]

Jonathan Coxhead writes:
 >    David wrote ...
 > 
 >  | Then the users makefile is broken and they no doubt will experience
 >  | many other problems.
 > 
 >    How on earth can you say "the user's makefile is broken"? It's 
 > just not the case! The makefile works fine!

If a makefile doesn't have dynamically generated dependencies, which
should include those of all libraries which are included in the
project, then surely it's broken?

 >  | The point is you should be supplying correct
 >  | code, not working around other peoples potential problems.
 > 
 >    I know that the point is to supply correct code. The only sense in 
 > which the code is "broken" at the moment is a sense that you have 
 > defined for yourself. That doesn't make it true!

The PRMs only refer to the file handles as being in a register - they
don't let you assume anywhere that it should be a byte.

 >  | I dont know of anyone supplying libraries for by third parties as
 >  | unlinked plain object files. All the libraries I've seen (and I 
 > have
 >  | most of them) are supplied as proper library chunk files which have
 >  | been partially linked against OSLib, so the problem doesn't arise.
 > 
 >    Again, you are making an assertion backed by nothing a vague sense 
 > of hope that that is how things ought to be. "Most" is not "all". In 
 > the real world, people don't always behave according to the way that 
 > you would most like.

And some people may have extensions which make use of perfectly legal
32-bit file handles - you are making the assumption that OSLib won't
be used on such systems.

 >  | > OSLib is a library, but it's also an interface.
 >  | 
 >  | A statically library's interface is defined by the header files 
 > not by
 >  | the binary object.
 > 
 >    Another assertion of an untrue fact. The interface has a *binary* 
 > definition. Why do you say this? I gave an example
 > 
 >       os_f f;
 > 
 >       ... xosfile_openin ("MyFile", &f) ...
 > 
 > that would break if the binary definition was changed. Please don't 
 > ignore the facts!

Not if os_f was an int...

 >    You can'y justify inflammatory phrases like "incorrect and 
 > potentially dangerous", "happens to work" and "just good luck" unless 
 > you have an example of a filing system that needs 32-bit handles. Do 
 > you?

Well there definitely won't be one that makes use of OSLib!  If one
wished to make one, OSLib in its current state wouldn't be suitable
for interacting with it.

 >  | It will only help people who have somehow managed bodge the
 >  | install of the library and mismatch the header and library files.
 > 
 >    Binary compatibility!

... for people who can't be bothered to install the new version of the
library and don't have makefiles that recognise the headers have changed.

 >    I suppose this is the real source of the disagreement. I did it as 
 > 8 because that's what I saw; I admit it was never documented 
 > explicitly, and choosing 32 bits may have been more sensible. But no 
 > matter where we think the mistake lies---my brain or the P R M---we 
 > have to make the best of it.

Well that's fair enough.

 > 
 >  | > code that exists today correctly assumes a file handle is a byte
 >  |                          ^^^^^^^^^
 >  |                          No!
 > 
 >    You can't argue with that---it's true!

File handles are generally granted in the range 0-255, that doesn't
mean that they're a byte!  They are returned in a register form a SWi,
and since values are generally word aligned it is just as efficient to
consider them as 32-bit entities.

 >  | My view is, ist better to flush out any problems at the earliest
 >  | stage. There is no bug worse than and old bug - as has happened 
 > here
 >  | it use because ingrained and it much more difficult to make changes
 >  | the longer you leave it.
 > 
 >    Well, sure. That means we should add the OS_W features now not 
 > later, so that everyone has a chance to upgrade. It doesn't mean we 
 > should silently break code for people who may be working in an 
 > entirely different area. Software is tricky enough to write when you 
 > only have your own bugs to worry about!
 > 
 >    We're still in a much better position than the UNIX world, with 
 > its lseek32(), llseek() and various other messes ...

Well that's not really a problem is it?  They have environments where
you just change a compiler flag and everything pretty much works
fine.  But then that's actually dealing with possibly different setups
- making code compilable even where largefile support isn't available,
this is a very different issue, 32-bit file handles are always
available and should be assumed _always_.  Of course if you wanted to
compile your code on an 8-bit BBC micro you might find that you  can
no longer have 32-bit file handles, but I think that would be the
least of your worries!

 >    I asked ...
 > 
 >  | > Does anyone have any sense of how likely 32-bit file handles are
 >  | > going to be?
 > 
 > and David replied ...
 > 
 >  | RISC OS would certainly
 >  | benefit being freed from this restriction from the days of the
 >  | BBC B's OS.
 >  | 
 >  | 32bit handles are also likely to be needed if any resource 
 > management
 >  | system is to be used, that can still allow inter-task handle 
 > sharing
 > 
 >    Well, sure, but that doesn't answer the question, does it? (Are 
 > you a politician? :-)
 > 
 >    There's a bit difference between something being desirable, and 
 > being feasible in a given timescale with given resources. I was 
 > asking more about the latter.

Well if it does start to use 32-bit file handles, there would
definitely have to be a recommendation that OSLib wasn't used or else
your file handling code might not work.  You could add a #define to
alter the behaviour, but it wouldn't really be meaningful - what would
you call it? ENABLE_8_BIT_FILEHANDLES?  To what ends?  So that some of
the object files in your project wouldn't have to recompiled (after
you'd bodged your makefile to make sure they weren't automatically)?

 >    So, you have 3 questions to answer, if you wouldn't mind:
 > 
 >    (1) Can you explain in what way you think maintaining 
 > compatibility can "only constrain the development of the library"?

If anyone tries using code form the library on a machine with a
perfectly legal filesystem that allocates filehandles above 255 then
strange things will occur and they won't have the faintest reason
why.  This will cause lack of confidence in the OS and the software.

If such code is allowed to persist in the library such problem will
continue to occur, and the name of the library and the OS will be
slurred, although the OS will get it harder because it's much less
likely that people will have heard of the library.

 >    (2) Is there an example of a filing system that needs 32-bit 
 > handles?

Was there an example of an application that needed more than 77 files
in a directory, or long filenames before they were available?  It
doesn't make the software correct to break if those limits aren't there.

 >    (3) Why do you think that it's bad for Microsoft to break 
 > backwards compatibility, but o k for OSLib to do so?

OSLib should be a true interface to the system calls.  The system call
returns an int, not a char.  If you'd returned the number of files
from gbpb for reading the number of files in a directory in a char
because it used to be limited to 77 would you insist that shouldn't be
changed either?

cheers,

P.S.  I've always thought OSLib was a quite astounding piece of work
and don't really think this is any reason to think any less of the
maintainers.

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