Files > 4GB

[Lewis T. Flynn]

In article <575 at siswat.UUCP> buck at siswat.UUCP (A. Lester Buck) writes:
[other stuff omitted]
>The HARD part is the file size limitation.  If you write your own
>filesystem, you can make the file sizes whatever you want, and can
>bring all the utilites and user code along with you.  But if you
>want to be able to use the existing Unix utilities and user code
>that "knows" that stat() returns a long for file size, you are stuck.
>The only transparent method that supports old code is to have the
>compiler support long as a 64 bit entity.  Cray has done this, I
>believe.  This is a serious efficiency hit on most other machines,
>where the architecture does not directly support 64 bit arithmetic.

This is pretty much true, but ignores the problem of binary
compatibility. We handled it under the general heading of "expanded
fundamental types" in which we relieved several size limits. For file
sizes, stat(), lseek(), and everything else which worries about offsets
and sizes now use the type "off_t" which in eft mode is a signed 64 bit
integer and in non-eft mode is the same old long we all knew and felt
luke warm about. Whether a program is in eft mode or not is a compile
time option (default non-eft) and libraries are provided for both
modes. 

What all this means is, if you don't need large files (or some other
eft feature), don't do a thing. Your binaries and compiles work as
before.  If you do want to take advantage of this stuff, you'll need to
make sure your source uses the correct types on certain system calls
and library routines and recompile with the eft option. All commands
shipped with UTS 2.1 are eft-ized (I think, I'll be corrected if I'm
wrong) and handle large files where feasible.

disclaimer: I'm not a spokesman for Amdahl and I believe this is all
documented in the manuals someplace.