[M3devel] what to do about file sizes being 32bits?

[Jay K]

> Not in the current release

Agreed.


I think I'll have this done in the next few days, with the
major caveat that it does break a lot of code. I'll fix the cm3 tree.


The breakage is roughly:


rd/wr users:
before:
  a := Rd.Length(b);
  c := Rd.Index(b);
  Rd.Seek(b, d);



after:
  a := ORD(Rd.Length(b));

  c := ORD(Rd.Index(b));


  Rd.Seek(b, VAL(d, LONGINT));




Though I think the last line should just work without change.


rd/wr implementers:
 more substantial changes, but still similar, lots of ORD/VAL, and "L".


One more compatible alternative might be to add LengthL, IndexL, 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.


To be clear though, the time for this change was 10 or 20 years ago.
Now, 32bit systems are going away and with them this problem.
(Amazingly, some 64bit systems still have 32bit time_t, like I think OpenBSD..)


 - Jay


> Date: Thu, 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?
> 
> Quoting hendrik at topoi.pooq.com:
> 
> > On Thu, Jan 07, 2010 at 06:59:31AM +0000, Jay K wrote:
> >>
> >> File.i3:
> >>
> >>
> >>   Status = RECORD
> >>     type: Type;
> >>     modificationTime: Time.T;
> >>     size: CARDINAL (* oops... *)
> >>   END;
> >>
> >>
> >> What to do?
> >> [0.. higher than 7FFFFFFF] doesn't "just work".
> >>    higher than 7FFFFFFFF is not legal on 32bit, unless you put "L"   
> >> on the end,
> >>    which presumably has some relationship to turning it into a   
> >> LONGINT, which
> >>    causes users to fail to compile
> >
> > In any case, 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.
> 
> Well, I don't think that should be any practical problem right now,
> shouldn't it? But 32 bit offsets have been overcome for years even
> on 32 bit systems, 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).
> 
> And please not for the still unfinished release, but for the next
> one.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/3fe806a3/attachment-0002.html>