int32 et al.
Bruce Worden
bruce at seismo.gps.caltech.edu
Sat Jan 19 08:39:06 AEST 1991
In article <14889 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>In article <26 at christmas.UUCP> rtm at island.COM (Richard Minner) writes:
>>I've gathered from this discussion (and others) that it is unlikely
>>that long will ever be implemented to be larger than int, unless int
>>is less than 32-bits (in a `quality' implementation?). Is this so?
>
>No, I would disagree. As file systems get ever larger, pressure to
>directly implement the (type "long") file offsets with more than 31-
>bit range will increase. Thus, even if the architecture encourages
>32-bit integer representation, "long" could well be implemented as
>e.g. a 64-bit quantity, simply to reduce hassles for customers of
>such systems.
Mr. (Dr.?) Gwyn makes an excellent point here. Disks of > 1Gbyte are
common and cheap now. I am working on a project where I had to implement
a simple file system with coarse-grained disk striping over several such
disks. Single files could exceed 4Gbytes, so we resorted to specifying
offsets and sizes in terms of logical blocks. This method was not much of
a problem for this application, but in other situations it would be much
less suitable or desirable. There is no question that >32 bit longs are
on the way, if for no other reason than support of big disks/file systems.
--------------------------------------------------------------------------
C. Bruce Worden bruce at seismo.gps.caltech.edu
252-21 Seismological Laboratory, Caltech, Pasadena, CA 91125
More information about the Comp.lang.c
mailing list