[m-rev.] for review: uint operations in array.m

[Julien Fischer]

On Sat, 3 Jan 2026 at 03:11, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
> On Sat, 3 Jan 2026 02:02:21 +1100, Julien Fischer <jfischer at opturion.com> wrote:
> > You will need to be particularly careful with this. Our target
> > languages impose a number of constraints on arrays.
> > The main two that are relevant here are that
> >
> > 1. In C# and Java, array index expressions have type int; indexes
> >    of other integral types will be implicitly converted (where allowed).
>
> I left the predicates implemented using foreign_procs using ints. None
> have been changed to use uints.
>
> > Obviously, some operations, such as size/1 will always be safe. I've noted
> > one group below that definitely are not in their present form and I think
> > correctness arguments need to be made for some of the others.
>
> Which others?

I was thinking primarily of array indexing operations (e.g. lookup, set).
It would be worth having a comment on one of them (probably lookup)
explaining why the uint indexing case is always safe.

> > > +uinit(Size, Item, Array) :-
> > > +    array.init_2(uint.cast_to_int(Size), Item, Array).
> >
> > As I mentioned above, this will be a problem. Consider, the following on a
> > system where int and uint are 32-bit:
> >
> >    array.uinit(2147483648u, "foo", Array)
> >
> > Ditto for all of the predicates and functions that create an array from a given
> > size in some way (e.g. generate and friends).
>
> Thanks for catching that. The attached interdiff covers those predicates.

That's fine, except for ...

> +    % Note that on backends that use fixed size 32-bit integers,
> +    % SizeI may be negative even though obviously Size cannot be.

It can also happen for 64-bit integers, it's just very unlikely someone
is doing that intentionally.  (The check is necessary in case it happens
by accident.)

> Do you have comments on the rest of the diff?

The rest looks fine.

Julien.