[M3devel] what to do about file sizes being 32bits?
Mika Nystrom
mika at async.async.caltech.edu
Thu Jan 7 18:47:28 CET 2010
Jay K writes:
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_
...
>One more compatible alternative might be to add LengthL=2C IndexL=2C SeekL?
>Maybe only break rd/wr implementers but not users?
>
>
>The reason I don't like that though is that it is even more of a no-op.
>Nobody will switch to the new functions.
>Similar to how "today" everybody will just ORD/VAL over the difference.
Isn't this what the <*OBSOLETE*> pragma is for?
Mika
>
>
>To be clear though=2C the time for this change was 10 or 20 years ago.
>Now=2C 32bit systems are going away and with them this problem.
>(Amazingly=2C some 64bit systems still have 32bit time_t=2C like I think Op=
>enBSD..)
>
>
> - Jay
>
>
>> Date: Thu=2C 7 Jan 2010 14:52:10 +0100
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] what to do about file sizes being 32bits?
>>=20
>> Quoting hendrik at topoi.pooq.com:
>>=20
>> > On Thu=2C Jan 07=2C 2010 at 06:59:31AM +0000=2C Jay K wrote:
>> >>
>> >> File.i3:
>> >>
>> >>
>> >> Status =3D RECORD
>> >> type: Type=3B
>> >> modificationTime: Time.T=3B
>> >> size: CARDINAL (* oops... *)
>> >> END=3B
>> >>
>> >>
>> >> What to do?
>> >> [0.. higher than 7FFFFFFF] doesn't "just work".
>> >> higher than 7FFFFFFFF is not legal on 32bit=2C unless you put "L" =
>=20
>> >> on the end=2C
>> >> which presumably has some relationship to turning it into a =20
>> >> LONGINT=2C which
>> >> causes users to fail to compile
>> >
>> > In any case=2C is the proper type for file offsets [0..7fffffffffffffff=
>]
>> > or [0..ffffffffffffffff]? I suspect the latter. It might take some
>> > effort to make that legal in Modula 3.
>>=20
>> Well=2C I don't think that should be any practical problem right now=2C
>> shouldn't it? But 32 bit offsets have been overcome for years even
>> on 32 bit systems=2C so I definitely think we should keep the LONGINT
>> type and even try to incompatibly change the internal file length
>> type (with due care and consideration of course).
>>=20
>> And please not for the still unfinished release=2C but for the next
>> one.
>>=20
>> Olaf
>> --=20
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C G=
>ermany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86=
> 95
>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: B=
>erlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214=
>194
>>=20
> =
>
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_
>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'>
>>=3B Not in the current release<br><br>Agreed.<br><br><br>I think I'll ha=
>ve this done in the next few days=2C with the<br>major caveat that it does =
>break a lot of code. I'll fix the cm3 tree.<br><br><br>The breakage is roug=
>hly:<br><br><br>rd/wr users:<br>before:<br> =3B a :=3D Rd.Length(b)=3B<=
>br> =3B c :=3D Rd.Index(b)=3B<br> =3B Rd.Seek(b=2C d)=3B<br>
><br><br>after:<br> =3B a :=3D ORD(Rd.Length(b))=3B<br>
> =3B c :=3D ORD(Rd.Index(b))=3B<br>
>
> =3B Rd.Seek(b=2C VAL(d=2C LONGINT))=3B<br>
>
><br><br>Though I think the last line should just work without change.<br><b=
>r><br>rd/wr implementers:<br> =3Bmore substantial changes=2C but still =
>similar=2C lots of ORD/VAL=2C and "L".<br><br><br>One more compatible alter=
>native might be to add LengthL=2C IndexL=2C SeekL?<br>Maybe only break rd/w=
>r implementers but not users?<br><br><br>The reason I don't like that thoug=
>h is that it is even more of a no-op.<br>Nobody will switch to the new func=
>tions.<br>Similar to how "today" everybody will just ORD/VAL over the diffe=
>rence.<br><br><br>To be clear though=2C the time for this change was 10 or =
>20 years ago.<br>Now=2C 32bit systems are going away and with them this pro=
>blem.<br>(Amazingly=2C some 64bit systems still have 32bit time_t=2C like I=
> think OpenBSD..)<br><br><br> =3B- Jay<br><br><br>>=3B Date: Thu=2C 7=
> Jan 2010 14:52:10 +0100<br>>=3B From: wagner at elegosoft.com<br>>=3B To:=
> m3devel at elegosoft.com<br>>=3B Subject: Re: [M3devel] what to do about fi=
>le sizes being 32bits?<br>>=3B <br>>=3B Quoting hendrik at topoi.pooq.com:=
><br>>=3B <br>>=3B >=3B On Thu=2C Jan 07=2C 2010 at 06:59:31AM +0000=
>=2C Jay K wrote:<br>>=3B >=3B>=3B<br>>=3B >=3B>=3B File.i3:<br>=
>>=3B >=3B>=3B<br>>=3B >=3B>=3B<br>>=3B >=3B>=3B Status =
>=3D RECORD<br>>=3B >=3B>=3B type: Type=3B<br>>=3B >=3B>=3B =
> modificationTime: Time.T=3B<br>>=3B >=3B>=3B size: CARDINAL (=
>* oops... *)<br>>=3B >=3B>=3B END=3B<br>>=3B >=3B>=3B<br>>=
>=3B >=3B>=3B<br>>=3B >=3B>=3B What to do?<br>>=3B >=3B>=3B =
>[0.. higher than 7FFFFFFF] doesn't "just work".<br>>=3B >=3B>=3B h=
>igher than 7FFFFFFFF is not legal on 32bit=2C unless you put "L" <br>>=
>=3B >=3B>=3B on the end=2C<br>>=3B >=3B>=3B which presumably h=
>as some relationship to turning it into a <br>>=3B >=3B>=3B LONGINT=
>=2C which<br>>=3B >=3B>=3B causes users to fail to compile<br>>=
>=3B >=3B<br>>=3B >=3B In any case=2C is the proper type for file offs=
>ets [0..7fffffffffffffff]<br>>=3B >=3B or [0..ffffffffffffffff]? I sus=
>pect the latter. It might take some<br>>=3B >=3B effort to make that l=
>egal in Modula 3.<br>>=3B <br>>=3B Well=2C I don't think that should be=
> any practical problem right now=2C<br>>=3B shouldn't it? But 32 bit offs=
>ets have been overcome for years even<br>>=3B on 32 bit systems=2C so I d=
>efinitely think we should keep the LONGINT<br>>=3B type and even try to i=
>ncompatibly change the internal file length<br>>=3B type (with due care a=
>nd consideration of course).<br>>=3B <br>>=3B And please not for the st=
>ill unfinished release=2C but for the next<br>>=3B one.<br>>=3B <br>>=
>=3B Olaf<br>>=3B -- <br>>=3B Olaf Wagner -- elego Software Solutions Gm=
>bH<br>>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 =
>Berlin=2C Germany<br>>=3B phone: +49 30 23 45 86 96 mobile: +49 177 2345=
> 869 fax: +49 30 23 45 86 95<br>>=3B http://www.elegosoft.com | Gesc=
>h=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin<br>>=3B Handelregister: Amtsg=
>ericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>>=3B <br> =
> </body>
></html>=
>
>--_17b8aaee-1301-49c7-aaf8-b79f42004b70_--
More information about the M3devel
mailing list