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

[Tony Hosking]

On 7 Jan 2010, at 15:33, Jay K wrote:

> I agree it isn't pretty but a big mistake was made many years ago, assuming file sizes are no larger than address spaces,
> and the current system might also not be so great (not allowing comparing a LONGINT to "0" or assigning it from an INTEGER).
> This seems to be about the best we can do.

I actually think it is *much* cleaner to have Rd/Wr.T sizes no larger than address spaces.  If someone really wants to use an OS-specific file size that is bigger than an address space then they can use the C interfaces, along with LONGINT.  If they are working with Rd/Wr then they don't need to mess with the ugliness.

>  Can we maybe have a system where are really just subranges, and INTEGER is just a pre-declared one?
> Therefore INTEGER and LONGINT somewhat interchangable?

Again, this contradicts the design principles of the Modula-3 type system.

>  Again, currently merely browsing to a directory with a large file raises an exception.

What code?  Does it use C interfaces or the Modula-3 interfaces?

>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Thu, 7 Jan 2010 14:07:03 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 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 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/6cd9744d/attachment-0002.html>