8 bit os_f handles

[Jonathan Coxhead]

   David wrote,

 | > When a library
 | > is provided by a third party, people just **do not** include
 | > dependencies on that library in their makefiles. If this were 
true,
 | > every makefile have dendencies on the version of the O S it was
 | > intended for, in case it need to be recompiled when the user did 
an
 | > upgrade!
 | 
 | Then they are wrong, and it should be specified in the library
 | instrucions.

   No, *you* are wrong in what you think the instructions should be.

   If OSlib came with instructions, they would be "OSlib provides 
binary compatibility indefinitely into the future, where the 
underlying O S permits it. Code compiled and linked on all versions 
of the O S will work in the same way on all past and future versions".

   This is a stronger guarantee than the one you would provide---
something like "OSLib provides a way of accessing SWI calls from C 
source, but the precise way in which it does this is subject to 
change without notice, so please recompile all your code every time 
you get a new release"?---and, admittedly, it has a cost. The cost is 
well worth paying.

 | > *You* may not like what those people do, but we are happy that 
 | > they are writing interesting code, and we are committed to 
keeping
 | > it working!
 | 
 | <Bangs head against desk in disbeif>

   Well, that says it all, really ...

 | >    It's not complacency at all, it's a natural consequence of 
what 
 | > happens in an evolving system. When files >2GB started appearing 
in
 | > UNIX, did anyone say, "let's make lseek() return a |long long|"? 
No.
 | > Instead, they intruduced llseek(). Same for us.
 | 
 | No No No different case. If they ever shipped a version with lseek
 | incorrectly returning a byte they would fix it.

   Sure, *if it was a bug*. We do fix bugs! But when they shipped a  
version of seek() that "incorrectly" (I guess you would say) returned 
an |int|, they did *not* fix it to return a long---they invented 
lseek() to do that. And now llseek(), for |long long|.

 | >  | Do any of the users in this mailing list have any code which 
will
 | >  | break if os_f is redesigned as a 32 bit, and the application |
 | >  recompiled? Its easy to tryout by just modifying the os.h 
header.
 | > 
 | >    This doesn't matter one bit. Hundreds of copies of OSLib have
 | >    gone 
 | > out, and I have no idea who's using them. Neither does anyone 
else.
 | > Even if the answer was "none", I'd still argue for compatibility:
 | > it's a professional ideal.
 | 
 | But changing it for future versions does not break existing 
versions
 | unless they are not recompiled properly. I do not know what is so
 | difficult to grasp about this.

   No-one has claimed anything else. Let me repeat your statement, 
but with the logic contraposed: "Changing it for future versions will 
break existing versions, unless they are recompiled". 

   Do you see why that is a bad thing?

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