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

[Zoltan Somogyi]

On Sat, 3 Jan 2026 04:03:54 +1100, Julien Fischer <jfischer at opturion.com> wrote:

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

Done, and ...

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

... done, as shown by the attached interdiff.

Zoltan.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: INTERDIFF2
Type: application/octet-stream
Size: 17010 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20260108/cd14197a/attachment.obj>