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

[Zoltan Somogyi]

On Mon, 5 Mar 2018 11:05:02 +1100, Peter Wang <novalazy at gmail.com> wrote:

> Hi Zoltan,
> > 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.

Yes, I read that comment, but I didn't know what it is trying to say.
Specifically, I didn't know why an unfilled enum would be represented
by a null, instead of a 0. But I see now that we represent *every*
unfilled value with a null, without testing its type.

> > 
> > 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.

We restrict the creation of type representations that put two or more
fields into the same word to the C backend with low-level data.
However, the argument packing code is executed for *every* backend.
I see now that test in pack_args for "are there any sub-word arguments"
was, in a roundabout way, effectively testing for low-level data as well.

> > 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.

It seems there are a couple of test cases with unfilled fields for
direct args, but I see none for packing. I will add some.

Thanks for your help.

Zoltan.