Article View: comp.arch
Article #22415Re: Multics & Memory mapped files
From: Stephen Tihor
Date: Tue, 13 Feb 1990 02:40
Date: Tue, 13 Feb 1990 02:40
18 lines
1520 bytes
1520 bytes
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.]
Technical Details
Message-ID:
<12780026@acf4.NYU.EDU>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!acf4!tihorReferences:
<5180@crdgw1.crd.ge.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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