Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!rcd
From: rcd@ico.isc.com (Dick Dunn)
Newsgroups: comp.unix.wizards
Subject: Re: bigger longs (64 bits)
Summary: isn't lseek() a separate problem?
Message-ID: <1990Feb12.195937.7661@ico.isc.com>
Date: 12 Feb 90 19:59:37 GMT
References: <11071@encore.Encore.COM>
Organization: Interactive Systems Corporation, Boulder, CO
Lines: 18

peralta@pinocchio.Encore.COM (Rick Peralta) writes:
> What are the feelings here regarding 64 bit longs?
. . .
> 	. larger disk storage
> 	  (no joke single volumes will be breaking lseek() soon)

Files are already breaking a 32-bit lseek pointer.  But shouldn't that one
be tackled differently?  The second argument to lseek should be an off_t,
not a long (and certainly not an int, as some have tried to inflict on us).

Perhaps the appearance of real uses for 64-bit integers and/or pointers
should cause us to think a little harder about the problems we've created
in the past.  The 16->32 transition was painful enough.

(Note that the "64-bit" discussion is also going on in comp.arch.)
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...Mr. Natural says, "Use the right tool for the job."