<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
> Not in the current release<br><br>Agreed.<br><br><br>I think I'll have this done in the next few days, 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 roughly:<br><br><br>rd/wr users:<br>before:<br> a := Rd.Length(b);<br> c := Rd.Index(b);<br> Rd.Seek(b, d);<br>
<br><br>after:<br> a := ORD(Rd.Length(b));<br>
c := ORD(Rd.Index(b));<br>
Rd.Seek(b, VAL(d, LONGINT));<br>
<br><br>Though I think the last line should just work without change.<br><br><br>rd/wr implementers:<br> more substantial changes, but still similar, lots of ORD/VAL, and "L".<br><br><br>One more compatible alternative might be to add LengthL, IndexL, SeekL?<br>Maybe only break rd/wr implementers but not users?<br><br><br>The reason I don't like that though is that it is even more of a no-op.<br>Nobody will switch to the new functions.<br>Similar to how "today" everybody will just ORD/VAL over the difference.<br><br><br>To be clear though, the time for this change was 10 or 20 years ago.<br>Now, 32bit systems are going away and with them this problem.<br>(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)<br><br><br> - Jay<br><br><br>> Date: Thu, 7 Jan 2010 14:52:10 +0100<br>> From: wagner@elegosoft.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] what to do about file sizes being 32bits?<br>> <br>> Quoting hendrik@topoi.pooq.com:<br>> <br>> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:<br>> >><br>> >> File.i3:<br>> >><br>> >><br>> >> Status = RECORD<br>> >> type: Type;<br>> >> modificationTime: Time.T;<br>> >> size: CARDINAL (* oops... *)<br>> >> END;<br>> >><br>> >><br>> >> What to do?<br>> >> [0.. higher than 7FFFFFFF] doesn't "just work".<br>> >> higher than 7FFFFFFFF is not legal on 32bit, unless you put "L" <br>> >> on the end,<br>> >> which presumably has some relationship to turning it into a <br>> >> LONGINT, which<br>> >> causes users to fail to compile<br>> ><br>> > In any case, is the proper type for file offsets [0..7fffffffffffffff]<br>> > or [0..ffffffffffffffff]? I suspect the latter. It might take some<br>> > effort to make that legal in Modula 3.<br>> <br>> Well, I don't think that should be any practical problem right now,<br>> shouldn't it? But 32 bit offsets have been overcome for years even<br>> on 32 bit systems, so I definitely think we should keep the LONGINT<br>> type and even try to incompatibly change the internal file length<br>> type (with due care and consideration of course).<br>> <br>> And please not for the still unfinished release, but for the next<br>> one.<br>> <br>> Olaf<br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH<br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> <br> </body>
</html>