[m-users.] foreign_type confusion on how to do it across modules...

[Zoltan Somogyi]

On Sun, 14 Jul 2019 15:54:58 -0700, M McDonough <foolkingcrown at gmail.com> wrote:

> On Sun, Jul 14, 2019 at 3:13 PM Zoltan Somogyi <zoltan.somogyi at runbox.com>
> wrote:
> 
> > How would the Mercury compiler know what to unbox? Given that most foreign
> > types
> > are typedef'd names, it has no idea which foreign types are pointers and
> > which are not.
> >
> > Zoltan.
> >
> 
> I thought that it gets stored as MR_Word which is GC malloc'ed using
> sizeof() on
> the native type, and in the prologue there is a macro which ends up being a
> memcpy into a local struct in that case?

That is correct.

Part of the context you snipped was "The foreign_proc should unbox the struct
(if it's not a pointer type)", and that is what I was replying to. Whether the Mercury
compiler does boxing and unboxing on a value whose type is defined in C depends
NOT on whether the C type is a pointer, since Mercury does not know that, but on
whether the C type's SIZE exceeds the size of the pointer. Mercury does not know
that either, but it can get the C compiler to make the decision for it by generating
a macro that invokes sizeof() and then does or does not do the relevant operation
(which may be boxing or unboxing) depending on the outcome of the size test.
And yes, the usual way to unbox a larger-than-pointer value is a memcpy.

However, Mercury never tests whether boxing and unboxing are needed on values
of types that programmers have told it can be passed around as Mercury types,
That optimization is what that assertion is FOR. Specifying that assertion
for a type that is bigger than a pointer, as emacstheviking's example did, is a bug.

Zoltan.