[M3devel] 32bit host 64bit target TextLiteral recurring problem

[Rodney M. Bates]

On 06/02/2015 08:58 PM, Jay K wrote:
> We cannot cross from 32bit host to 64bit target.
>
>
> Ok to commit this?
>
> diff --git a/m3-libs/m3core/src/text/TextLiteral.i3 b/m3-libs/m3core/src/text/TextLiteral.i3
> index fa72589..37bf238 100644
> --- a/m3-libs/m3core/src/text/TextLiteral.i3
> +++ b/m3-libs/m3core/src/text/TextLiteral.i3
> @@ -12,9 +12,16 @@ UNSAFE INTERFACE TextLiteral;
>   IMPORT RTHooks, TextClass;
>   CONST
> - (* DIV BITSIZE should not be here! *)
> +(* When cm3 uses TInt and when pickle special cases this, it should be approx:
> +    MaxBytes = LAST (INTEGER) - BITSIZE (INTEGER) * 2 *)
> +(* This fails for 32bit host and 64bit target:
> +    MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7; *)
> +(* Until/unless unpickling special cases this, it must not be sizeof(INTEGER)
> +   dependent. *)
> + (* DIV BITSIZE should not be here -- compiler limitation due to
> +    non-use of TInt. *)
>    (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *)
> - MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7;
> + MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 15;
>       (* - 8 * ORD(BITSIZE(INTEGER) = 64) *)
>       (* Do not adjust this for INTEGER size.  It makes T have different
>          fingerprints on 32- and 64-bit machines, which undermines pickling/
>
>
> Yes I know TEXT pickles will be broken.
> I propose that unpickle should special case a few values here.
> Or, isn't the brand supposed to help?
> Or, can we encode this in a better way, w/o an upper bound?
> I know if you put in 0..0 or 0..-1 you incur range violations at runtime.
> Which makes me wonder -- are TEXTs unsafe?
>
> Should we support a syntax something like:
>
>      cnt : INTEGER;
>      buf : ARRAY [0..cnt - 1] OF Byte;
> ?
>

Can't do this.  Non-open arrays must have static constant bounds,
which the above does not.  Open arrays have extra dope and are accessed
through two extra pointers, which we really wouldn't want for text literals.

TextLiteral.Ts are unsafe only in UNSAFE code, which is no worse that anything
else in UNSAFE code.  The interface is UNSAFE, which means safe code can't IMPORT
it, and thus can't see the declaration.  Not very likely that anybody other than
the runtime, compiler-generated code, and debugger (written in C anyway) would
want to mess with it.

> Thanks,
>   - Jay

-- 
Rodney Bates
rodney.m.bates at acm.org