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

[Jay K]

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/20100107/16b32603/attachment-0001.html>