8 bit os_f handles

Tue Mar 28 21:12:17 BST 2000

   Daniel wrote,

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

   No, because the person who wrote it trusts us.

   Since we have guaranteed that the interface won't change in an 
incompatible way, thay can write their makefile without needing an 
explicit dependency on the libraries that it uses. This means they 
can upgrade their libraries without worrying about recompiling their 
entire source base, and is a Good Thing [tm :-)], and in fact an 
indispensible one.

   This is normal practice anyway. If a UNIX makefile contains the 
line

      prog: prog.c
         cc -o prog prog.c -lm

do you think it should also have

      prog: /usr/lib/libm.a

? Because this is *not* normal practice.

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

   What you say is true. I was being slightly naughty, and using my 
knowledge of RISC O S internals. Sackcloth and ashes time for 
Jonathan :-( 

 | I gave an example [...] that would break if the binary
 | definition was changed. Please don't ignore the facts!
 | 
 | Not if os_f was an int...

   If wishes were horses, we could all feast on roast cheval every 
Sunday lunchtime. Facts are facts, however much we wish they weren't.

 | Do you [have an example of a filing system that needs 32-bit
 | handles?

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

   True, but irrelevant. As I asked David, "are you a politician?"
:-) A 32-bitly-handled file system couldn't use OSLib, *but* is there 
one? My claim is that there isn't, because FileSwith in *loaded* with 
assumptions that handles are 8 bits wide.

   In that case, the subject under discussion is, "should we huild in 
support now for a possible future rewrite of FileSwitch that can cope 
with >255 open files?"

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

   By saying "can't be bothered", you are implying that they are 
lazy. What would happen, do you think, if whenever you installed a 
new version of the O S, you had to recompile all your applications? 
Chaos! The reason you don't have to do that is that the new version 
of the O S provides binary compatibility with the old one. 

   That's for a whole operating system! How much easier it is to 
provide the same service for a single library? A lot! Of course, we 
should do so.

   True*, and if I did it again, I might make a different choice. But 
if you look at FileSwitch, you discover that internally, at least, 
file handles *really are* a byte. It did not seem so unreasonable 
then to advertise that assumption in the interface. A shame.

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

   While it would be possible to provide some sort of flag to allow 
the same source code be used with 8- or 32-bit handles, I would be 
strongly against it.It would confuse everyone by making the same 
source code compile into 2 very different objects.

   A nicer idea would be to provide a means to "turn off" 8-bit 
handles. This allows error-finding to be switched on when a client 
decides to upgrade their code. You can do this by writing

      #define os_f junk

      #include "osfile.h"
      ... other OSLib includes ...

      #undef os_f

at the top of your source file. Any occurrence of |os_f| in your code 
will be undefined, and the compiler will happily find all your uses 
of it, which you can then turn into |os_w|. Now that's what I call an 
easy---and reliable---upgrade path!

   I don't think that OSLib itself should do this, though---it's 
something that's quite sensible an as application coding style, but 
not something that should be in the library itself.

 | How likely are 32-bit file handles going to be?
 | 
 | Well if it does start to use 32-bit file handles, there would
 | definitely have to be a recommendation that OSLib wasn't used

   In its current form, of course. But we can extend, as we always do.

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

   Agreed, as above.

 |  >    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 is true, and a shame, but easy to fix. A version of OSLib can 
only supply interfaces to a given version of a given module. To use 
new facilities of a new 32-bit FileSwitch will need new interfaces to 
those facilities---which we will provide, as we always do!

 |  This will cause lack of confidence in the OS and the software.

   That much is true---if you get a file handle > 255, but you are 
using |os_f|, it will be silently truncated. This is not a good state 
of affairs, but all we can do is make it as easy as possible to 
upgrade to 32-bit handles, and advertise the fact that you have to do 
it.

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

   You're evading the question, but you raise a valid point. However, 
the FileSwitch *interface* does not limit directory entries to 77, or 
file names to 10 characters---else, how does NFS work? It does limit 
file handles to 1 byte (in my, and therefore OSLib's interpretion), 
and so a change to *that* is an interface change. Other future 
changes may imply other interface changes---and some other changes 
may leave the interface unchanged. (We prefer those :-)

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

   Yes, I would---of course I would. I can't imagine that you might 
think I would give any other answer, if you have understood what I've 
been saying at all.

   Luckily for all concerned, I didn't!

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

   Thank you!

   *except it's 1--255

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