[m-dev.] questions about null vs 0 in argument packing

[Peter Wang]

Hi Zoltan,

On Sun, 04 Mar 2018 16:06:12 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> I have questions about the behavior of argument packing
> with respect to NULL pointers. It seems to me that the MLDS
> code generator is transforming mlconst_nulls into mlconst_int(0)s
> almost randomly, and wondering why this is not a problem
> on the C# and Java backends. (I don't expect this to be a problem
> for C, since in C, NULL is just a 0 with a cast.)
> 
> The problematic chain of calls is this.
> 
> - pack_args (in arg_pack.m) is given a list of rvals, which may
>   include mlconst_nulls.
> 
> - If all the rvals are full words, then the arguments, including any
>   mlconst_nulls, are left alone.
> 
> - If some are *not* full words, then pack_args calls do_pack_args,
>   which invokes ShiftCombine on every rval, even when that rval
>   is not being packed.
> 
> - The caller of arg_pack in ml_unify_gen.m will specify
>   ml_shift_combine_rval or ml_shift_combine_rval_type
>   as ShiftCombine. Both of those predicates apply ml_lshift
>   to every rval, even the ones not being packed together
>   with anything else.
> 
> - ml_lshift replaces mlconst_nulls with mlconst_int(0)s,
>   presumably because this is the right thing to do for values being
>   packed, but I don't know whether a value being packed
>   (which at the moment is always an enum) can ever be mlconst_null.
> 
> All of this means that whether a full word mlconst_null in a cell
> being constructed is replaced with mlconst_int(0) depends on the
> "random" answer to the question: is there another word in the cell
> that contains two or more packed arguments?
> 
> My questions are:
> 
> 1 Was this semi-random conversion behavior designed or did it
>   just happen? If it was designed, what is the reason for it?

The replacing of nulls with zeroes is given by this comment ml_lshift:

    % We may get nulls from unfilled fields. Replace them with zeroes
    % so we don't get type errors from the C compiler.

Any other (unpacked) null getting replaced with zero should be
accidental, I would think.

> 
> 2 Has this semi-random conversion led to any problems
>   in programs using the C# or Java backends?
> 

No, as explained by this comment in handle_options.m:

    % Argument packing only works on C back-ends with low-level data.

> 3 If not, why not? My understanding is that in C# and Java,
>   a null is NOT the same as 0.
> 

That's right.

> 4 Would anyone object if I changed things so that mlconst_nulls
>   that are not being packed were left alone? This *would* generate
>   different C# and Java code than before, whose validity I cannot check.
> 

Go ahead.

> 5 Would anyone object if I changed things so that mlconst_nulls
>   that *are* being packed aborted the compiler, so we could check
>   whether such things actually occur? I would commit this only
>   if it passed bootcheck in hlc.gc, obviously, but I can't bootcheck it
>   in C# or Java.

As long as we have a test case that tries to pack fields with unfilled
fields, if there is not one already.

Peter