[m-dev.] questions about null vs 0 in argument packing
zoltan.somogyi at runbox.com
Sun Mar 4 16:06:12 AEDT 2018
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
- 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?
2 Has this semi-random conversion led to any problems
in programs using the C# or Java backends?
3 If not, why not? My understanding is that in C# and Java,
a null is NOT the same as 0.
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.
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.
More information about the developers