8 bit os_f handles

[David J. Ruck]

On Tue 28 Mar, Jonathan Coxhead wrote:
>    David wrote,
> 
>  | If source files are not dependant on all headers included
>  | (automatically generated dependencies using AMU and Acorn Make) and
>  | the executable isn't dependant on the library the make file is 
> broken.
> 
>    Look, you are doing yourself no good at all by repeating, over and 
> over again, the same damn thing. It's still not true! 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.

> 
>    We *do* support those who rely on features such as supplying 
> unlinked object files! Also, those who want to write binary 
> structures to disc and read them back, those who want to do remote 
> procedure call bindings including arbitrary O S types, and every 
> other bizarre, baroque and creative use of the library that we 
> haven't thought of. 
> 
>    *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>

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

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

---Dave

-- 
______________________________________________________________________

  David J. Ruck     Phone: 07974 108301     Email: druck at freeuk.com
______________________________________________________________________