Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!usc!jarthur!nntp-server.caltech.edu!bruce
From: bruce@seismo.gps.caltech.edu (Bruce Worden)
Newsgroups: comp.lang.c
Subject: Re: int32 et al.
Message-ID: <1991Jan18.213906.6626@nntp-server.caltech.edu>
Date: 18 Jan 91 21:39:06 GMT
References: <26@christmas.UUCP> <14889@smoke.brl.mil>
Sender: bruce@seismo.gps.caltech.edu (Bruce Worden)
Organization: California Institute of Technology, Pasadena
Lines: 24
Nntp-Posting-Host: sis.gps.caltech.edu

In article <14889@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>In article <26@christmas.UUCP> rtm@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@seismo.gps.caltech.edu
252-21 Seismological Laboratory, Caltech, Pasadena, CA 91125