Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!acf4!tihor
From: tihor@acf4.NYU.EDU (Stephen Tihor)
Newsgroups: comp.arch
Subject: Re: Multics & Memory mapped files
Message-ID: <12780026@acf4.NYU.EDU>
Date: 13 Feb 90 02:40:00 GMT
References: <5180@crdgw1.crd.ge.com>
Organization: New York University
Lines: 18

Even fixing the file pointer to be unsigned you need an integer type 
large enough to contains someting from { your address space, your dataspace}
or if you are really agressive {all know data}.  As seek dies a well desrved
death fpos* will help some since the opaque objects can get bigger.
But until C is replaced by C++ or ADa or Multla-3 or some language that 
permits definitions of things such as + on opauqe types people will have
problems doing real work.  I know poeple with real, production system that
exceed 32 bits of addressible bytes casually and are pushing 48 bits.  

You can dismiss such things as unlikely.  Then you must explain to them
how "UNIX is the FUTURE" when it makes them do painful things to work.
Frankly we need additional clean primitives, new concepts, which frankly
have not been being added to the UNIX at any reasonable rate.

[Example: the ELXSI unix-like but designed rom scratch OS EMBOS unified
the procedurable namespace with the file name space so object libraries 
were the same as directories in may senses.  A perfect "UNIX style" idea.
Ain't in Research 9 or AT&T SV.4 or on any up and coming lists I have seen.]