[M3devel] 64bit file sizes now?

[Tony Hosking]

On 11 Jan 2010, at 22:46, Jay K wrote:

> True that:
>  
> > (LAST(INTEGER) + 1) = FIRST (INTEGER)
> 
>  
> many folks would like to see fail before it gets to the "=".

WIthout overflow checking the addition will not fail.

>  
> The dilemna remains though because:
>  
> > (LAST(INTEGER) + 1L) = FIRST (INTEGER)

Actually, you mean VAL(LAST(INTEGER), LONGINT) + 1L

> would not fail.
> 
> So, you can either look at it as they produce different values, or one succeeds and one fails.

The point is that the type explicitly tells you whether you might be in trouble with overflow.

> Either way people don't like two different expressions doing two different things.
> Again, converting an INTEGER to a LONGINT is one of the simplest things you can do.
>  
> There something here about "transitivity" or "replacement":
>  
> j2 := VAL(i1, LONGINT) + j3;
> vs.
> j2 := i1 + j3;

It is not referentially transparent.  It requires innate knowledge about promotion rules to understand.  That's what "not referentially transparent" means!

>  
> pretty clearly have the same meaning.
> The conversion is always trivial and always succeeds.
> Does anyone really find it ambiguous?
>  
>  - Jay
> 
>  
> > Date: Tue, 12 Jan 2010 03:27:23 +0000
> > From: dabenavidesd at yahoo.es
> > To: m3devel at elegosoft.com; jay.krell at cornell.edu
> > Subject: Re: [M3devel] 64bit file sizes now?
> > 
> > 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
> > > 
> > > 
> > > 
> > 
> > 
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/59d798f0/attachment-0002.html>