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

Thu Jan 7 21:31:31 CET 2010

Given that files are in fact larger than 4GB, why should we impose such a limit?

Doesn't it make for a pretty lame system?

Pretty much no existing 32bit C system for many years now any such limit and

C started going past these limits around 15 years ago.

It turns out changes I sent were pretty nearly done. I can now build all of "std"

with LONGINT for file sizes. It's not just Rd/Wr, though that is most of it, it is also "File".

 - Jay

Subject: Re: [M3devel] what to do about file sizes being 32bits?
From: hosking at cs.purdue.edu
Date: Thu, 7 Jan 2010 14:17:40 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: hosking at cs.purdue.edu

I guess what I am really saying is that it does not seem unreasonable to me that Modula-3 (as a language) should be able to restrict the Rd.T and Wr.T instances to have a length that is always expressible as INTEGER.  That was the point of my question about eliminating LONGINT.  With the C interfaces abstracted, LONGINT would no longer be necessary.

Antony Hosking | Associate Professor | Computer Science | Purdue University

305 N. University Street | West Lafayette | IN 47907 | USA
Office  +1 765 494 6001  +1 765 494 6001  | Mobile  +1 765 427 5484  +1 765 427 5484 

On 7 Jan 2010, at 14:07, Tony Hosking wrote:

Jay,

I am *very* concerned that these changes are damaging the clarity of the language and its libraries in bad ways.  What is so unreasonable about having the Modula-3 library interfaces place restrictions that continue to impose INTEGER file sizes.  Just because the underlying OS allows files larger than that, if a program creates and manipulates files through the standard interfaces then they cannot ever see file sizes bigger than INTEGER.  The interfaces support failure of Put operations on Wr.T that permit us to fail when exceeding the restricted file size.  Please do not make these changes in the mainline trunk until further discussion.  If you want to propose a set of changes I strongly suggest that you place them in a branch for evaluation by others!

-- Tony

On 7 Jan 2010, at 12:26, Jay K wrote:

> 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  +49 30 23 45 86 96  mobile:  +49 177 2345 869  +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/ce27e7fb/attachment-0002.html>