[m-rev.] for review: fix a bug in the string to int and uint overflow checks

[Julien Fischer]

On Sat, 18 Jul 2026 at 06:37, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
> On Fri, 17 Jul 2026 23:23:53 +1000, Julien Fischer <jfischer at opturion.com> wrote:

> > > I would rename this to either accumulate_positive_int
> > > or accumulate_non_negative_int.
> >
> > Renamed to the former, which is more consistent with the surrounding predicates.
>
> What I meant was that it should depend on whether zero is
> an allowed input or not.

Zero is allowed as an input by both accumulator predicates. The decision
on which to use is based on the value of the sign character if present
and the implied value of the sign character (positive) if it is absent.

> > Java provides both, C and C# provide only truncating division.
> > The Mercury standard library implements flooring division (div)
> > in Mercury for all of our signed integer types. We only require
> > that the target languages provide truncating division.
> >
> > > If you know, it would help to mention them here.
> >
> > How is what the target languages provide relevant here?
>
> Having the target language implement natively the kind of division
> we want to use can reduce overheads, but you are right, this is probably
> not that significant.

I'm not aware of any common ISAs that provide instructions for flooring integer
division.  If a target language provides it, they are most probably doing
so in a similar way to us.

Julien.