[M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?

[Jay K]

So..we can't fully cross build a 64bit target from a 32bit host because some code
wants to declare arrays that fill memory, like so that indexing them never fails
an overflow check:


TYPE T = ARRAY [0..LAST(INTEGER)] OF CHAR; for example 


I'm faced with a few choices:
 - do nothing 
 - have the front end pin the sizes to its maximum
    Leading to such code to fail if it actually operates on data larger than 2GB
 - use Target.Int a lot more, and in parse.c TARGET_INTEGER more, INTEGER less
 - use LONGINT a lot more (zero vs. a lot), and in parse.c "long long" in place of "long",
     (roughly: "long" suffices instead on most 64bit systems)
  - possibly a hybrid of previous two: Target.Int in m3middle/m3front, long long in parse.c


Extremely similarly btw:


TYPE T1 = ARRAY [0..16_LAST(INTEGER) DIV 4] OF CHAR; for example 
TYPE T2 = RECORD a,b,c:T1; END;


which is just to say, it isn't just about total array sizes, but also field offsets.


(I'll add the obvious: this is the sort of thing where C++ operator overloading really shines...)



I'm dreading that the sort of conservative/portable answer -- Target.Int and TARGET_INTEGER, will touch *a lot* of code.
e.g. m3front/src/types/Type.i3/Info, and then all its users.

Should these types use a different and unsafe form?
Do we have a convenient unsafe form?

 - Jay