[M3devel] 64bit file sizes now?

Mika Nystrom mika at async.async.caltech.edu
Tue Jan 12 06:53:49 CET 2010 

Why not change the implementation to something using LONGINT (or
BigInteger.T...)  and then provide the old ones as a thin veneer over
the new implementation, marking the old ones as <*OBSOLETE*>...

    Mika


Jay K writes:
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Large files (64bit file sizes) are very old.
>
>Windows 95 had them in the released API 14+ years ago (1995)=2C NT a few ye=
>ars before that (1993?)=2C betas earlier. I heard VMS had 64bit file sizes =
>but I haven't confirmed.
>
>=20
>
> > If the use-case is typically INTEGER then perhaps we
> > need to think of alternatives using abstraction?
>=20
>
>Hm. StatusLong=2C SeekLong=2C IndexLong=2C LengthLong?
>
>Default calls Seek/Index/Length=2C range checked truncation?
>
>Kind of an annoying duplicity of APIs though.
>
>=20
>
> - Jay
>=20
>
>
>From: hosking at cs.purdue.edu
>Date: Mon=2C 11 Jan 2010 22:10:06 -0500
>To: jay.krell at cornell.edu
>CC: m3devel at elegosoft.com
>Subject: Re: [M3devel] 64bit file sizes now?
>
>
>
>
>On 11 Jan 2010=2C at 22:02=2C Jay K wrote:
>
>
>So.. LONGINT as I understand will remain roughly as it was=2C except VAL(ex=
>pr=2C INTEGER) is how you convert expr to INTEGER=2C instead of ORD(expire)=
>.
>
>
>
>That's what I think makes most sense.
>
>
> And this is already in place.
>
>
>
>Yes=2C it's in place.
>
>
>
>?
>=20
>So I should go ahead and update File.i3/Status/size and Rd/Wr/Index/Seek/Le=
>ngth to all be LONGINT=2C "whatever the consequences"? The consequences are=
> roughly the first diff I sent out=2C with the caveats that I used ORD() in=
>stead of VAL(=2CINTEGER)=2C and a few packages were left to fix. It is mech=
>anical and simple and predictable=2C just tedious and ugly.
>Most Rd/Wr users are limited to INTEGER "sizes" anyway=2C but a few might g=
>ain capacity.
>Classic simple example is the mklib and libdump code=2C they read the entir=
>e file into memory and then deal with that.
>
>
>
>If the use-case is typically INTEGER then perhaps we need to think of alter=
>natives using abstraction?
>
>
> I can send the diffs ahead of time=2C but there's really no choices left a=
>s to what they'll look like=2C it is forced by the limited capability of LO=
>NGINT.
>Had they used LONGINT in the first place=2C of course=2C there'd be no diff=
> at this time=2C the ugliness would have been builtin from the start.
>
>When they originally wrote it large file sizes were only proposed not imple=
>mented.  I don't think C even had long long then.  (Yes=2C I am showing my =
>age! -- we are talking almost 20 years ago now!)  If they had used LONGINT =
>from the start then folks would have not had any ugliness because all would=
> have used LONGINT.    Now=2C to save some hassles in future=2C perhaps we =
>need a better abstraction!  Let's ponder that before you propagate your cha=
>nges.
>
> 		 	   		  =
>
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>Large files (64bit file sizes) are very old.<BR>
>Windows 95 had them in the released&nbsp=3BAPI 14+ years ago (1995)=2C NT a=
> few years before that (1993?)=2C betas earlier. I heard VMS had 64bit file=
> sizes but I haven't confirmed.<BR>
>&nbsp=3B<BR>
><DIV>&nbsp=3B&gt=3B If the use-case is typically INTEGER then perhaps we</D=
>IV>
><DIV>&nbsp=3B&gt=3B need to think of alternatives using abstraction?</DIV>
>&nbsp=3B<BR>
>Hm. StatusLong=2C SeekLong=2C IndexLong=2C LengthLong?<BR>
>Default calls Seek/Index/Length=2C range checked truncation?<BR>
>Kind of an annoying duplicity of APIs though.<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR>&nbsp=3B<BR>
><HR id=3DstopSpelling>
>From: hosking at cs.purdue.edu<BR>Date: Mon=2C 11 Jan 2010 22:10:06 -0500<BR>T=
>o: jay.krell at cornell.edu<BR>CC: m3devel at elegosoft.com<BR>Subject: Re: [M3de=
>vel] 64bit file sizes now?<BR><BR><BASE>
><DIV><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLL=
>APSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPA=
>CING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxAppl=
>e-style-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BOR=
>DER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LE=
>TTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=
>=3DecxApple-style-span>
><DIV style=3D"WORD-WRAP: break-word"><SPAN style=3D"TEXT-TRANSFORM: none=3B=
> TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B W=
>HITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WO=
>RD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D"TEXT-TRANSFORM:=
> none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvet=
>ica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C=
>0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D"TEXT-TR=
>ANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B FONT: 12p=
>x Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COLOR: rgb(=
>0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN style=3D=
>"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separate=3B F=
>ONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B COL=
>OR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-span><SPAN =
>style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPSE: separ=
>ate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACING: norma=
>l=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-style-spa=
>n><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER-COLLAPS=
>E: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTER-SPACIN=
>G: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3DecxApple-s=
>tyle-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORDER=
>-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: normal=3B LETTE=
>R-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" class=3Dec=
>xApple-style-span><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=
>=3B BORDER-COLLAPSE: separate=3B FONT: 12px Helvetica=3B WHITE-SPACE: norma=
>l=3B LETTER-SPACING: normal=3B COLOR: rgb(0=2C0=2C0)=3B WORD-SPACING: 0px" =
>class=3DecxApple-style-span>
><DIV><SPAN style=3D"FONT-SIZE: medium" class=3DecxApple-style-span>On 11 Ja=
>n 2010=2C at 22:02=2C Jay K wrote:</SPAN></DIV></SPAN></SPAN></SPAN></SPAN>=
></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></SPAN></DIV>
><DIV><BR class=3DecxApple-interchange-newline>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>So.. LONGINT as I understand will remain roughly as it was=2C except VAL(e=
>xpr=2C INTEGER) is how you convert expr to INTEGER=2C instead of ORD(expire=
>).<BR></DIV></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>That's what I think makes most sense.</DIV><BR>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>&nbsp=3BAnd this is already in place.<BR></DIV></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>Yes=2C it's in place.</DIV>
><DIV><BR></DIV>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>?<BR>&nbsp=3B<BR>So I should go ahead and update File.i3/Status/size and R=
>d/Wr/Index/Seek/Length to all be LONGINT=2C "whatever the consequences"? Th=
>e consequences are roughly the first diff I sent out=2C with the caveats th=
>at I used ORD() instead of VAL(=2CINTEGER)=2C and a few packages were left =
>to fix. It is mechanical and simple and predictable=2C just tedious and ugl=
>y.<BR>Most Rd/Wr users are limited to INTEGER "sizes" anyway=2C but a few m=
>ight gain capacity.<BR>Classic simple example is the mklib and libdump code=
>=2C they read the entire file into memory and then deal with that.<BR></DIV=
>></SPAN></BLOCKQUOTE>
><DIV><BR></DIV>
><DIV>If the use-case is typically INTEGER then perhaps we need to think of =
>alternatives using abstraction?</DIV><BR>
><BLOCKQUOTE><SPAN style=3D"TEXT-TRANSFORM: none=3B TEXT-INDENT: 0px=3B BORD=
>ER-COLLAPSE: separate=3B FONT: medium Helvetica=3B WHITE-SPACE: normal=3B L=
>ETTER-SPACING: normal=3B WORD-SPACING: 0px" class=3DecxApple-style-span>
><DIV style=3D"FONT-FAMILY: Verdana=3B FONT-SIZE: 10pt" class=3Decxhmmessage=
>>&nbsp=3BI can send the diffs ahead of time=2C but there's really no choice=
>s left as to what they'll look like=2C it is forced by the limited capabili=
>ty of LONGINT.<BR>Had they used LONGINT in the first place=2C of course=2C =
>there'd be no diff at this time=2C the ugliness would have been builtin fro=
>m the start.</DIV></SPAN></BLOCKQUOTE><BR></DIV>
><DIV>When they originally wrote it large file sizes were only proposed not =
>implemented. &nbsp=3BI don't think C even had <FONT class=3DecxApple-style-=
>span face=3DCourier>long long</FONT>&nbsp=3Bthen. &nbsp=3B(Yes=2C I am show=
>ing my age! -- we are talking almost 20 years ago now!) &nbsp=3BIf they had=
> used LONGINT from the start then folks would have not had any ugliness bec=
>ause all would have used LONGINT. &nbsp=3B &nbsp=3BNow=2C to save some hass=
>les in future=2C perhaps we need a better abstraction! &nbsp=3BLet's ponder=
> that before you propagate your changes.</DIV>
><DIV><BR></DIV> 		 	   		  </body>
></html>=
>
>--_7e4b65ed-7d03-496f-8734-2648c7e5ee94_--

More information about the M3devel mailing list