[M3devel] 64bit file sizes now?

[Daniel Alejandro Benavides D.]

Hi all:
forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
(LAST(INTEGER) + 1) = FIRST (INTEGER)
This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code.   
Please let me know if I'm wrong about this issue on current discussions. 

--- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribió:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] 64bit file sizes now?
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 11 de enero, 2010 22:02
> 
> 
> 
> 
>  
> So.. LONGINT as I understand will remain roughly as it was,
> except VAL(expr, INTEGER) is how you convert expr to
> INTEGER, instead of ORD(expr).
> 
>  
> 
>  
> 
> And this is already in place.
> 
>  
> 
>  
> 
> ?
> 
>  
> 
>  
> 
> So I should go ahead and update File.i3/Status/size and
> Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
> the consequences"? The consequences are roughly the
> first diff I sent out, with the caveats that I used ORD()
> instead of VAL(,INTEGER), and a few packages were left to
> fix. It is mechanical and simple and predictable, just
> tedious and ugly.
> Most Rd/Wr users are limited to INTEGER "sizes"
> anyway, but a few might gain capacity.
> 
> Classic simple example is the mklib and libdump code, they
> read the entire file into memory and then deal with that.
> 
>  
> 
>  
> 
> I can send the diffs ahead of time, but there's really
> no choices left as to what they'll look like, it is
> forced by the limited capability of LONGINT.
> 
> Had they used LONGINT in the first place, of course,
> there'd be no diff at this time, the ugliness would have
> been builtin from the start.
> 
>  
> 
>  
> 
>  - Jay
> 
>  		 	   		  
>