[M3devel] va/loophole/integers

[Jay K]

I admit I didn't read all the code or try a test -- so the range check could be there already, yes.

 > LOOPHOLE in the language expects values with equal BITSIZE

Ok. So the assert I added is redundant, but that's ok, asserts usually are.

> Perhaps we should use widen/chop?

Sounds promising.

I admit I'm just not sure. The current code doesn't seem terrible.
General pattern: Lots of things are surprising (not intuitive) when first discovered.
But that doesn't make them wrong or unreasonable.

 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sun, 31 Oct 2010 13:51:14 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] va/loophole/integers
>
> On Oct 31, 2010, at 3:20 AM, Jay K wrote:
>
> > When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.
>
> Possibly. LOOPHOLE in the language expects values with equal BITSIZE. I used it originally because LOOPHOLE as implemented seemed to do the right thing. Probably we should use widen/chop (as defined in M3CG_Ops.i3).
>
> > I think this is wrong in multiple ways.
> >
> >
> > For 64bit targets, nothing should be done.
> > Backend can check that it is given equal types.
> > This might already be done.
>
> If they are same BITSIZE then loophole is appropriate, no?
>
> > A range check should be done.
>
> We have a range check in VAL:
>
> Expr.GetBounds (ce.args[0], minu, maxu);
> EVAL Type.GetBounds (t, mint, maxt);
> IF TInt.LT (minu, mint) THEN
> (* we need a lower bound check *)
> IF TInt.LT (maxt, maxu) THEN
> (* we also need an upper bound check *)
> ce.args[0] := CheckExpr.New (ce.args[0], mint, maxt,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> ELSE
> ce.args[0] := CheckExpr.NewLower (ce.args[0], mint,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> END;
> ELSIF TInt.LT (maxt, maxu) THEN
> (* we need an upper bound check *)
> ce.args[0] := CheckExpr.NewUpper (ce.args[0], maxt,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> END;
>
>
> > Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.
>
> This *will* raise an exception if it doesn't fit.
>
> > Code that wants to ignore this can..well..it takes a bit if code I guess, but still.
> > Similarly for LONGCARD to CARDINAL
>
> Should be the same.
>
> > And then, still, I don't think loophole is appropriate.
> >
> > Perhaps loophole in backend isn't meant to match up to loophole in the language?
> > I guess, maybe, but this seems...not intuitive.
>
> Perhaps we should use widen/chop?
>
> > In particular I tried making loophole use VIEW_CONVERT and I was look at the
> > affect here:
> >
> > libm3/.../FilePosix.m3
> >
> > PROCEDURE RegularFileSeek(
> > h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
> > : INTEGER RAISES {OSError.E} =
> > BEGIN
> > WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
> > IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
> > RETURN VAL(result, INTEGER)
> > END
> > END RegularFileSeek;
> >
> >
> >
> > (1034) call_direct procedure:Unix__lseek type:int64
> > (1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
> > (1036) store var:noname offset:0 src_t:int64 dst_t:int64
> > (1037) begin_block
> > (1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
> > (1039) load var:noname offset:0 src_t:int64 dst_t:int64
> > (1040) store var:result offset:0 src_t:int64 dst_t:int64
> > (1041) set_source_line 0x96(150)
> > (1042) load_integer type:int32 0
> > (1043) loophole type1:int32 type2:int64
> >
> >
> >
> > and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.
> >
> >
> > Probably the backend should check that loophole is using two equal sized types, and then use view convert.
> > Though for now at least it has to deal with these integer conversions.
> >
> >
> > - Jay
> >
> >
>