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

[Jay K]

I apologize for not paying close attention at the time.

That seems to make sense to me now.

 

 

There is at least an in-between version where INTEGER

is assignable to LONGINT.

 

 

In your proposal, the amount of source change required would be

I think very very little. Some code would "just work" with large files,

and some code would fail.

 

 

 - Jay

 
> Date: Thu, 7 Jan 2010 19:35:20 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> 
> I addressed all these details in my original LONGINT proposal, but it
> didn't get much attention at the time. That would have been October
> of 2007. I can't find the posts right now, because the link
> http://mailarchive.elegosoft.com/Zope/m3/m3devel is broken, and I have
> too many email account changes to be able to find it in my own
> inboxes.
> 
> I proposed, and still do, that LONGINT be an ordinal type. This has
> the consequence, by preexisting rules, that INTEGER and LONGINT would
> be assignable to each other. This does not violate the preexisting
> language precedent, in fact, it is exactly like the preexisting rules
> for INTEGER and all its subtypes--they are assignable if the value is
> in the LHS type.
> 
> This eliminates the necessity for the ORD and VAL conversions in most
> places, where there are mixtures of the types. Most places in the
> language require only assignability, not type equality. Exceptions
> include passing to a VAR formal and use in a type definition of a new
> type.
> 
> A consequence of existing rules is that there would be, if necessary,
> runtime value checks. In many cases, including the examples we are
> discussing here, assigning a LONGINT to an INTEGER could well
> introduce a bug when a value is out of range, but this is no different
> from what happens when ORD/VAL are coded explicitly.
> 
> On the other side of this argument, the necessity of coding ORD/VAL
> would point out statically, places where value range errors should be
> ruled out by the programmer. A conscientious programmer would then
> make an informed decision whether to just insert ORD/VAL, or whether
> it was necessary to change the INTEGER variable to LONGINT. But
> again, the already existing rules for subranges don't do this, so
> making INTEGER and LONGINT assignable would be consistent.
> 
> Note that right now, the current implementation has a linguistic
> contradiction in that, if subranges of LONGINT are allowed, then
> LONGINT is an ordinal type, which implies LONGINT and INTEGER are
> mutually assignable. This could, of course be fixed in the language,
> but I would prefer making the two types assignable.
> 
> 
> 
> 
> 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
> > 
> > 
> > LONGINT doesn't "just work"
> > causes users to fail to compile
> > 
> > 
> > stale imports -> compiling ProcessPosixCommon.i3
> > stale imports -> compiling ProcessPosixCommon.m3
> > stale imports -> compiling ProcessPosix.m3
> > stale imports -> compiling FileRd.i3
> > missing version stamps -> compiling FileRd.m3
> > "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN
> > "../src/rw/FileRd.m3", line 140: types are not assignable
> > 2 errors encountered
> > stale imports -> compiling FileWr.i3
> > missing version stamps -> compiling FileWr.m3
> > "../src/rw/FileWr.m3", line 92: incompatible argument types: MIN
> > "../src/rw/FileWr.m3", line 108: incompatible argument types: MAX
> > 2 errors encountered
> > st
> > 
> > 
> > Change it to LONGINT, fix all the callers, and hope the damage isn't too 
> > great outside the cm3 tree?
> > 
> > 
> > Change it to LONGINT only for 32bit platforms, somehow author the cm3 
> > tree to work either way,
> > hope the damage isn't too great outside the cm3 tree?
> > 
> > 
> > Change it to LONGREAL so that it works immediately on NT386.
> > Same issues as above, breaks existing users.
> > 
> > 
> > Maybe relax the language some, so that e.g.
> > a:INTEGER;
> > b:LONGINT;
> > 
> > b := a;
> > 
> > just works, see if it helps make more code compile with the change?
> > 
> > a := b is problematic of course, but what is wrong with b := a?
> > 
> > - Jay
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/9394f4b3/attachment-0002.html>