[M3devel] va/loophole/integers

[Jay K]

When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.


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.


A range check should be done.
Truncating a LONGINT to a INTEGER should 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

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.

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