Integer-to-string conversion error solved

[Nelson H. F. Beebe]

The problem of incorrect conversion to strings of the most negative
integers, which have no positive counterpart in two's complement
arithmetic (standard on all major CPUs built since the 1980s), has
been solved.

See the section entitled "Integer-to-string conversions in ga68" at

        https://www.math.utah.edu/~beebe/algol68/

There are several new test files in the latest bundle,
utah-ga68-2026-07-09.tar.gz.

I hope that ga68 compiler and/or library maintainers can soon fix this
problem, so that future gcc releases will have the repairs.

It also raises an issue of internal string buffer sizes. At present,
ga68 offers 8-bit (short short int), 16-bit (short int), 32-bit (int),
and 64-bit (long int) types, along with unsigned companions where
"int" becomes "bits".  Further "long" modifiers do not add precision
(as demonstrated by one of the test files).

The clang, gcc, and icc compilers for C programs have supported
128-bit integer arithmetic for several years, even though there is not
yet a way to write such long integers in code, or to input and output
them with formatted I/O.  Some recent CPU designs already support
128-bit arithmetic in hardware.  The inttostr.c test file uses 128-bit
integers when it detects compiler support for them, and I have
successfully tested them with gcc compilers on ARM64 (Aarch64),
Loong64, PowerPC, RISC-V64, S390, SPARC, and x86_64 CPUs.

Thus, when ga68 supports 128-bit integers (and even 256-, 512-, ...
longer sizes), the conversion buffer sizes may need to be increased.

My test code for both Algol 68 and C includes assertions to check for
such an oversight, and terminate the job if the buffer is too small.
In separate experiments, with too-small buffers, I verified that the
assertions catch the errors.  Because the buffer is filled in reverse
order, with the lowest-order digit converted first, it needs a fixed
size at compile time, rather than exploiting Algol 68's flex arrays
that grow as needed.

Longer integers are exceedingly useful in some applications, of which
cryptography and multiple-precision arithmetic are important ones.
Algol 68 is unusual in that it allows compilers to support any number
of "long" modifiers, up to some documented limit.  The availability of
the well-tested gmp and mpfr libraries for binary integer and
floating-point arithmetic, and the decNumber library for decimal
arithmetic, means that extending ga68 for just one longer type should
quickly generalize to supporting several longer types.

Finally, to get the new code recorded in the algol68 mailing list
archives, here is a fragment from the inttostr-algol-v2.a68 file for
64-bit integers, with a buffer size [160] that can handle up to
512-bit integers:

    proc posrem = (long int num, long int den) long int :
    begin
        long int r;
        r := ABS (num - (num OVER den) * den)
    end;

    proc inttostr = (long int value) string:
    begin
        [160] char buf;
        bool isneg := false;
        int last := 160;
        long int v;

        v := value;
        isneg := v < long 0;

        if v = (long 0) then
            assert(last > 0);
            buf[last] := "0";
            last -:= 1
        fi;

        while v /= long 0
        do
            int digit;
            digit := SHORTEN posrem(v, long 10);
            assert(last > 0);
            buf[last] := "0123456789?"[digit + 1];
            last -:= 1;
            v := v OVER long 10
        od;

        assert(last > 0);
        buf[last] := if isneg then "-" else "+" fi;

        buf[last:]
    end;

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                                                          -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: https://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------