[m-rev.] for review: Don't cast int32/uint32 to MR_Word in foreign code input assignments.

[Zoltan Somogyi]

On Thu, 1 Oct 2026 15:45:31 +1000, Peter Wang <novalazy at gmail.com> wrote:
> > For this to work by design instead of by accident, we have to ensure that
> > the type of the integer we output here is the same as, or at least is
> > automatically castable to, the declared type of the foreign language
> > variable representing that input arg. That type is decided by whatever
> > code sets the third field of the foreign_proc_arg_decl given to
> > output_foreign_proc_decls, which is not in that file. You should find
> > that code, and add a link to it here.
> 
> Do you mean the 2nd field of foreign_proc_arg_decl?

Yes.

> That code is in make_foreign_proc_decl:
> 
>         (
>             BoxPolicy = bp_native_if_possible,
>             OrigTypeString = exported_type_to_c_string(ModuleInfo, OrigType)
>         ;
>             BoxPolicy = bp_always_boxed,
>             OrigTypeString = "MR_Word"
>         ),
>         ArgDecl = foreign_proc_arg_decl(OrigType, OrigTypeString, ArgName),
> 
> exported_type_to_c_string calls exported_builtin_type_to_c_string
> which returns the C types for the fixed sized integer types.

The attached diff documents this link, and a problem with it.

> > I am surprised that we do not treat 8 and 16 bit ints/uints the same way
> > we now treat 32 and 64 bit. Why? If writing them out as lt_word is fine,
> > there should be a comment explaining *why* it is fine.
> 
> You're right, 8- and 16-bit ints have the same issue.

And I eventually realized that the same is true for word-size ints/uints.
The attached diff, which I am committing, fixes this as well.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.loi
Type: application/octet-stream
Size: 6526 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20261002/fcf35a69/attachment.obj>