GCC and Gfortran 3.1 released

[Thomas Koenig]

The GCC developers are proud to announce a new major GCC release, 13.1.

Apart from many bug fixes and enhancement this release includes
the following Fortran-relevant changes:

Fortran: Finalization is now fully supported.

OpenMP 5.0: Fortran now supports some non-rectangular loop nests;
for C/C++, the support was added in GCC 11.

Behavior on integer overflow

GCC 13 includes new optimizations which may change behavior on
integer overflow. Traditional code, like linear congruential
pseudo-random number generators in old programs and relying on
a specific, non-standard behavior may now generate unexpected
results. The option -fsanitize=undefined can be used to detect
such code at runtime.

It is recommended to use the intrinsic subroutine RANDOM_NUMBER for
random number generators or, if the old behavior is desired, to use
the -fwrapv option. Note that this option can impact performance.

Please find more details at https://gcc.gnu.org/gcc-13/changes.html
and https://gcc.gnu.org/gcc-13/porting_to.html .

Enjoy!

[Thomas Koenig]

... should have been that Subject, of course.

[Thomas Koenig]

I wrote

> Behavior on integer overflow
>
> GCC 13 includes new optimizations which may change behavior on
> integer overflow. Traditional code, like linear congruential
> pseudo-random number generators in old programs and relying on
> a specific, non-standard behavior may now generate unexpected
> results. The option -fsanitize=undefined can be used to detect
> such code at runtime.
>
> It is recommended to use the intrinsic subroutine RANDOM_NUMBER for
> random number generators or, if the old behavior is desired, to use
> the -fwrapv option. Note that this option can impact performance.
>
> Please find more details at https://gcc.gnu.org/gcc-13/changes.html
> and https://gcc.gnu.org/gcc-13/porting_to.html .

... and would have expected at least some comments on this one.

Did nobody read it, or have all uses outside of the Polyhedron
test suite for linear congruential pseudo-random number generators
vanished?

[Steven G. Kargl]

Oh, there was much wailing and nashing of teeth in Fortran Discourse.
Comment 83 in https://fortran-lang.discourse.group/t/gfortran-releases/2704/90
starts the discussion, and I've deleted my comments as it was going no
where. In the rnflow.f90 code, the lcg has essentially
'integer, parameter :: jmul ..., jadd'. Giving either the 'volatile'
attribute defeats the new behavior.

--
steve

[Thomas Koenig]

Steven G. Kargl <s...@REMOVEtroutmask.apl.washington.edu> schrieb:

I just looked through it, and it seems people didn't read the advice
to use -fwrapv.

And as far as linear congruential generates are concerned: I
guess the current advice is to just use C's unsigned numbers,
until the time when unsigned numbers are finally added to Fortran.

[Steven G. Kargl]

I re-iterated that advice in one of my comments and also
showed that -fsanitize=undefined gives a runtime warning
that undefined behavior was occurring.

In fact, if the LCG of rnflow.f90 were in another file,
say,lcg.f90 and compiled separately, there is no problem.
As is, gfortran in-lines rnflow's lcg and then the
optimizers can see the initial seed will cause a signed
integer overflow.

> And as far as linear congruential generates are concerned: I
> guess the current advice is to just use C's unsigned numbers,
> until the time when unsigned numbers are finally added to Fortran.

That's what I do for both a prng and hashes.

--
steve

[gah4]

On Wednesday, May 10, 2023 at 11:30:00 AM UTC-7, Thomas Koenig wrote:

(snip)

> And as far as linear congruential generates are concerned: I
> guess the current advice is to just use C's unsigned numbers,
> until the time when unsigned numbers are finally added to Fortran.

More generally, it is sometimes nice to be able to a multiply,
signed or unsigned, and get the double length product.

No high-level languages seem to make that easy.

For C compilers, if you cast 32 bit (long) to (long long) and
multiply, most will do a 32 bit multiply with 64 bit product.
I believe also for (unsigned long long).

It is also sometimes nice to be able to do a divide with double
length dividend, as most hardware allows.

I am not sure by now, which hardware supports a 64x64 multiply
with 128 bit product, or divide with 128 bit dividend. If some do,
it would be nice to be able to use it.

[Ron Shepard]

On 5/10/23 2:21 PM, Steven G. Kargl wrote:
>> And as far as linear congruential generates are concerned: I
>> guess the current advice is to just use C's unsigned numbers,
>> until the time when unsigned numbers are finally added to Fortran.

> That's what I do for both a prng and hashes.

On the other hand, sometimes it is nice to be able to eat at your own
restaurant. This seems to be important enough that it should be fixed
within the fortran compilers, and not be required to use C interop. In
this case, it is something that fortran programmers have been doing for
decades, and now we can't (at least not without special compilation flags).

I like the idea that now integer overflows can be detected in gfortran.
Usually, you don't want an integer overflow to be silent. But then there
are these cases where the programmer does want that behavior. There
should be some way for us to have our cake and eat it too.

$.02 -Ron Shepard

[Steven G. Kargl]

Here's your cake.

1. Compile your code with -fsanitize=undefined.
2. Run your code.
a) Code runs without error/warning.
Done.
b) Code fails to run with error/warning.
I. Recompile code with -fwrapv.
or
II. Isolate section of code with issue
and recompile it with -fwrapv.
or
III. Compile with -fno-inline. Go to 1.
or
IV. Read code. Change one or more
'parameter' attribute(s) to 'volatile'.
3. Request J3 to add an 'unsigned' attribute to
the Fortran standard.
4. Add an extension to gfortran to have an
'unsigned' attribute.

--
steve

[Ron Shepard]

On 5/11/23 9:14 AM, Steven G. Kargl wrote:
> On Thu, 11 May 2023 01:52:48 -0500, Ron Shepard wrote:

[...]

> 3. Request J3 to add an 'unsigned' attribute to
> the Fortran standard.
> 4. Add an extension to gfortran to have an
> 'unsigned' attribute.

First, there are lots of situations where unsigned arithmetic would be
nice to have in fortran, so I'm all for that. That is about 40 or 50
years late to the language in my opinion.

However, for the LCG situations, this seems to me to be kind of a
gimmick to solve this problem. In C, unsigned integer arithmetic is
basically defined to be mod 32 arithmetic. That is, overflows with
unsigned arithmetic are ignored.

What if you want overflows with unsigned arithmetic to be caught the
same way they are for signed arithmetic? C has already made its choice,
what is done is done there. But in fortran, is mod 32 arithmetic really
what is best for the language? I don't think that answer is obvious.

I think my preferred solution from all of the possibilities is to have a
pair of fortran intrinsic functions just for this special case. One does
additions with overflow ignored and the other does multiplications with
overflow ignored. Of course, compilers should inline those functions for
efficiency (they map directly to the hardware, after all), but the
programmer would then be in control in those few situations where silent
overflow (or mod 32 arithmetic) is desired. No compiler options or
volatile attributes should be required.

If such functions were added to the language, then there are still some
choices. Should they work for all integer kinds, or just the kind that
is the same size as an address (e.g. 64 bits)? Or maybe just the default
integer kind (e.g. 32 bits)? As a programmer, I would like all kinds to
be supported, but if that is too difficult for compiler writers, then I
would gladly settle for something less general just have have it
available. (Thoughts of PDTs that are still buggy in compilers come to
mind.)

Another related issue is that it is too difficult in fortran to move
bits from one integer kind into another integer kind. The MVBITS()
operator should be generalized to allow the FROM and the TO arguments to
be different kinds.

$.02 -Ron Shepard

[Thomas Koenig]

gah4 <ga...@u.washington.edu> schrieb:

> On Wednesday, May 10, 2023 at 11:30:00 AM UTC-7, Thomas Koenig wrote:
>
> (snip)
>
>> And as far as linear congruential generates are concerned: I
>> guess the current advice is to just use C's unsigned numbers,
>> until the time when unsigned numbers are finally added to Fortran.
>
> More generally, it is sometimes nice to be able to a multiply,
> signed or unsigned, and get the double length product.

$ cat a.f90
program memain
use iso_fortran_env
integer(kind=int32) :: a, b
integer(kind=int64) :: c

read (*,*) a, b
c = int(a,kind=int64) * int(b,kind=int64)
print *,a,b,c
end program memain
$ gfortran a.f90
$ echo "12345678 23456789" | ./a.out
12345678 23456789 289589963907942

(And compilers have been smart enough for a few decades to use
widening multiply in such situations).

> No high-level languages seem to make that easy.

I think the cod above is fairly easy.

>
> For C compilers, if you cast 32 bit (long) to (long long) and
> multiply, most will do a 32 bit multiply with 64 bit product.
> I believe also for (unsigned long long).

Yes (also not hard).

> It is also sometimes nice to be able to do a divide with double
> length dividend, as most hardware allows.
>
> I am not sure by now, which hardware supports a 64x64 multiply
> with 128 bit product,

These days, any 64-processor does.

>or divide with 128 bit dividend. If some do,
> it would be nice to be able to use it.

That, I believe, is not so generally implemented in hardware.

[Steven G. Kargl]

On Thu, 11 May 2023 11:02:22 -0500, Ron Shepard wrote:

> On 5/11/23 9:14 AM, Steven G. Kargl wrote:
>> On Thu, 11 May 2023 01:52:48 -0500, Ron Shepard wrote:
> [...]
>
>> 3. Request J3 to add an 'unsigned' attribute to
>> the Fortran standard.
>> 4. Add an extension to gfortran to have an
>> 'unsigned' attribute.
>
> First, there are lots of situations where unsigned arithmetic would be
> nice to have in fortran, so I'm all for that. That is about 40 or 50
> years late to the language in my opinion.
>
> However, for the LCG situations, this seems to me to be kind of a
> gimmick to solve this problem. In C, unsigned integer arithmetic is
> basically defined to be mod 32 arithmetic. That is, overflows with
> unsigned arithmetic are ignored.

Unsigned integer overflow has a defined behavior in C.

Signed integer overflow is undefined behavior in C.

Fortran does not have unsigned integers.

Depending on processor-dependent behavior for a prohibited
construct in the Fortran standard seems to be a poor programming
practice. For a poorly written lcg(), the processor-dependent
behavior is exposed for

seed = 1234567
i = lcg(seed)

iff lcg(seed) can be in-lined and you use -O (or higher optimization).
You have been told 4 ways to defeat the compiler. (1) Use -fwrapv.
(2) Put lcg() in a separate file and compile it. (3) Use -fno-inline.
(4) Use -fsanitize=undefined (getting an error message, but desired
behavior).

A fifth possibility is to not depend on processor-defined behavior.
The LCG that I use was designed to avoid integer overflow. I gave
you the reference to the paper.

Instead of making a mountain out of molehill, recompile all your
codes with gfortran 13.1 and -O3. Run your unit tests. If a
test fails, recompile and run it with -fsanitize=undefined to
see if this particular issue is something that you should fix
in your code.

--
steve

[Thomas Koenig]

Ron Shepard <nos...@nowhere.org> schrieb:

> On 5/11/23 9:14 AM, Steven G. Kargl wrote:
>> On Thu, 11 May 2023 01:52:48 -0500, Ron Shepard wrote:
> [...]
>
>> 3. Request J3 to add an 'unsigned' attribute to
>> the Fortran standard.

There is https://github.com/j3-fortran/fortran_proposals/issues/2
for which I have written up a proposal which is supposed to be
submitted to J3.

Attached below for comment and further refinement.

>> 4. Add an extension to gfortran to have an
>> 'unsigned' attribute.

If this ever makes any headway at J3, I've committed to implementing
them. It would make an interesting project, probably with a lot
of repetetive code.

> First, there are lots of situations where unsigned arithmetic would be
> nice to have in fortran, so I'm all for that. That is about 40 or 50
> years late to the language in my opinion.

> However, for the LCG situations, this seems to me to be kind of a
> gimmick to solve this problem. In C, unsigned integer arithmetic is
> basically defined to be mod 32 arithmetic. That is, overflows with
> unsigned arithmetic are ignored.

They are not ignored, there is no overflow in mod 2^n arithmatic.

> What if you want overflows with unsigned arithmetic to be caught the
> same way they are for signed arithmetic? C has already made its choice,
> what is done is done there. But in fortran, is mod 32 arithmetic really
> what is best for the language? I don't think that answer is obvious.

If you want to check for overflow on addition with unsigned
integers, this is trivial:

c = a + b
if (c < a) then ! overflow occurred

For multiplication, you'll need a widening multiplication and to check
for overflow.

> I think my preferred solution from all of the possibilities is to have a
> pair of fortran intrinsic functions just for this special case. One does
> additions with overflow ignored and the other does multiplications with
> overflow ignored. Of course, compilers should inline those functions for
> efficiency (they map directly to the hardware, after all), but the
> programmer would then be in control in those few situations where silent
> overflow (or mod 32 arithmetic) is desired. No compiler options or
> volatile attributes should be required.

I've proposed such intrinsics, too. For GCC, these would just
be builtin functions, which can easily be called from gfortran.

> If such functions were added to the language, then there are still some
> choices. Should they work for all integer kinds, or just the kind that
> is the same size as an address (e.g. 64 bits)?

All kinds.

> Or maybe just the default
> integer kind (e.g. 32 bits)? As a programmer, I would like all kinds to
> be supported, but if that is too difficult for compiler writers, then I
> would gladly settle for something less general just have have it
> available. (Thoughts of PDTs that are still buggy in compilers come to
> mind.)

PDTs are a different kettle of fish. Implementing such functions from
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html would
not be too hard.

[...]

And here's the unsigned proosal in its current form:

To: J3 J3/XX-XXX
From: Thomas König
Subject: UNSIGNED type
Date:

# 1. Introduction

Unsigned integers, are a basic data type used in many programming
languages, like C. Arithmetic on them is typically performed modulo
2^n for a datatype with n bits. They are useful for a range of
applications, including, but not limited to

- hashing
- cryptography (including multi-precision arithmetic)
- image processing
- binary file I/O
- interfacing to the operating system
- signal processing
- data compression

Introduction of unsigned integers should not repeat the mistakes of
languages like C, and syntax and functionality should be familiar to
people who today use unsigned types in other programming languages.

# 2. C interoperability

One major use case is C interoperability, including interfacing to
operating system calls specified in C. At the moment, Fortran uses
signed int for interoperability with C unsigned int types, which has
two drawbacks:

## 2.1 Value range

An unsigned int with n bits has a value range between 0 and 2^n-1,
while Fortran model numbers have values between -2^(n-1)+1 and
2^(n-1)-1. While agreement of representation between nonzero
interoperable Fortran integers and nonnegative unsigned ints on
a companion processor is assured by the C standard, this is not
the case for unsigned ints larger than 2^(n-1)-1.

## 2.2 Automatically generated C headers

It is straightforward to generate C prototypes or declarations
suitable for inclusion in the companion processor from Fortran
interfaces. At least one compiler, gfortran, has an
[option to do this](https://gcc.gnu.org/onlinedocs/gfortran/Interoperability-Options.html).
This fails in the case where the C code specifies unsigned, and
Fortran can only specify interoperable signed integers.

# 3. Avoiding traps and pitfalls

There are numerous well-known traps and pitfalls in the way that C
implements unsigned integers. These are mostly the result of C's
integer promotion rules, which need to be avoided. Specifically,
comparison of signed vs. unsigned values can lead to confusion,
which can lead to hard-to-detect errors in the code, infinite
loops, and similar.

# 4. Prior art

At least one Fortran compiler, Sun Fortran, introduced unsigned ints.
Documentation can be found at
[Oracle](https://docs.oracle.com/cd/E19205-01/819-5263/aevnb/index.html).
This proposal borrows heavily from that prior art, without sticking
to it in all details. The discussion at the [Fortran proposals
site](https://github.com/j3-fortran/fortran_proposals/issues/2) also
influenced this proposal.

# 5. Proposal

## 5.1 General

- A type name tentativily called UNSIGNED, with the same KIND
mechanism as for INTEGER, plus a SELECTED_UNSIGNED_KIND FUNCTIONS,
to implement unsigned integers

- Unsigned integers are marked with an U suffix, with an optional
KIND number following

- A conversion function UINT, with an optional KIND

- A prohibition of mixing INTEGER and UNSIGNED operands on binary
operands. It is to be decided if a positive integer constant
should be valid as an operand together with an unsgined value.

- Binary operations between INTEGER and UNSIGNED are prohibited
without explicit conversion, binary operations between UNSIGNED
and REAL are permitted

- Unsigned integers to be allowed in SELECT CASE

- Unsigned integers not to be allowed as index variables in a DO
statement or array indices

- Unsigned integers can be be read or written in list-directed,
namelist or unformatted I/O, and by using the usual edit
descriptors such as I,B,O and Z

- Extension of ISO_C_BINDING with KIND numbers like C_UINT, C_UINT8_T etc

- Likewise, the ISO_FORTRAN_ENV should be extended.

- Behavior on conversion to integer outside the range of the integer
should be processor-dependent, and identical to the behavior of
the companion C processor.

## 5.2 Behavior on overflow

In the discussion on github, two possible behaviors on overflow were
discussed: That this should be forbidden (using a "shall" directive)
and that this should wrap around.

The author of this proposal is of the opinion that wrap-around semantics
(modulo 2^n for an n-bit type) should be specified, for several reasons:

- It is required for several applications which would otherwise be left
to C, such as cryptography, hashes and big-integer arithmetic

- The standard does not (up to now) mandate run-time checks, and an
implementation which does not perform overflow checks would perform
the same operation as with modulo 2^n arithmetic

- Writing checks for overflow with user code is relatively straightforward.
For example,
```
c = a + b
if (c < a) then ! overflow occurred
```
but only possible if the operation to be checked is not, in fact, illegal.
Over time, compilers will tend to remove such checks because they cannot
be true because of the langauge definition (compare the removal of NULL
pointer checks in C).

# 6. Relation to other proposals

This proposal complements the BITS proposal, J3/07-007r2.pdf, as
proposed in J3/22-195.txt. BITS restricts its operations to logical
operations and comparisons on bit lengths, whereas this proposal is
for values requiring arithmetic operations, and is less flexible
in bit length.

[Thomas Koenig]

Steven G. Kargl <s...@REMOVEtroutmask.apl.washington.edu> schrieb:

> Instead of making a mountain out of molehill, recompile all your
> codes with gfortran 13.1 and -O3. Run your unit tests. If a
> test fails, recompile and run it with -fsanitize=undefined to
> see if this particular issue is something that you should fix
> in your code.

While I concur with the advice in principle, I would recommend
running the unit tests with -fsanitize=undefined -fcheck=all -g
after having compiled with -Wall -Werror.

Also, if you happen to have access to nagfor, use their -C=all flag.
You will be surprised at the bugs coming crawling out of the woodwork,
I promise you :-)

[gah4]

On Thursday, May 11, 2023 at 9:04:36 AM UTC-7, Ron Shepard wrote:

(snip)

> I think my preferred solution from all of the possibilities is to have a
> pair of fortran intrinsic functions just for this special case. One does
> additions with overflow ignored and the other does multiplications with
> overflow ignored. Of course, compilers should inline those functions for
> efficiency (they map directly to the hardware, after all), but the
> programmer would then be in control in those few situations where silent
> overflow (or mod 32 arithmetic) is desired. No compiler options or
> volatile attributes should be required.

> If such functions were added to the language, then there are still some
> choices. Should they work for all integer kinds, or just the kind that
> is the same size as an address (e.g. 64 bits)? Or maybe just the default
> integer kind (e.g. 32 bits)? As a programmer, I would like all kinds to
> be supported, but if that is too difficult for compiler writers, then I
> would gladly settle for something less general just have have it
> available. (Thoughts of PDTs that are still buggy in compilers come to
> mind.)

Note that this problem does not happen in C.
All types smaller than int are promoted to int before any operation.

Multiplying two 8 bit char (or unsigned char) values will never overflow.

It seems, though, that Fortran defines even the smallest INTEGER kinds
to have the same KIND result for add, subtract, multiply, and divide.

In any case, as I mentioned previously, it would be nice to have easy
access to double length product and dividend. Such functions could
offer those, even when double length is larger than an existing KIND.

[gah4]

On Thursday, May 11, 2023 at 9:04:36 AM UTC-7, Ron Shepard wrote:

(snip)

> However, for the LCG situations, this seems to me to be kind of a
> gimmick to solve this problem. In C, unsigned integer arithmetic is
> basically defined to be mod 32 arithmetic. That is, overflows with
> unsigned arithmetic are ignored.

> What if you want overflows with unsigned arithmetic to be caught the
> same way they are for signed arithmetic? C has already made its choice,
> what is done is done there. But in fortran, is mod 32 arithmetic really
> what is best for the language? I don't think that answer is obvious.

As well as I remember it, Fortran has been ignoring integer
overflow since long before I started learning it in 1972.
Long enough for programmers to depend on it.

It was known to trap floating point overflow and integer
divide, but not integer overflow. That gets slightly complicated
as sign magnitude and ones' complement used to be not so rare.

The Fortran rules still allow for sign magnitude and digit complement,
and at any integer radix greater than one. The use of multiply for
random number generators goes pretty far back, though.

[Steven G. Kargl]

On Thu, 11 May 2023 15:54:43 -0700, gah4 wrote:

> On Thursday, May 11, 2023 at 9:04:36 AM UTC-7, Ron Shepard wrote:
>
> (snip)
>
>> However, for the LCG situations, this seems to me to be kind of a
>> gimmick to solve this problem. In C, unsigned integer arithmetic is
>> basically defined to be mod 32 arithmetic. That is, overflows with
>> unsigned arithmetic are ignored.
>
>> What if you want overflows with unsigned arithmetic to be caught the
>> same way they are for signed arithmetic? C has already made its choice,
>> what is done is done there. But in fortran, is mod 32 arithmetic really
>> what is best for the language? I don't think that answer is obvious.
>
> As well as I remember it, Fortran has been ignoring integer
> overflow since long before I started learning it in 1972.
> Long enough for programmers to depend on it.

Fortran compilers of yesteryears may have ignored it, but
the Fortran standards did not:

Fortran 77, page 6-20

Any arithmetic operation whose result is not mathematically defined
is prohibited in the execution of an executable program.

Fortran 66, page 12

No element may evaluated whose vlue is mathematically defined.

--
steve

[gah4]

On Thursday, May 11, 2023 at 7:08:35 PM UTC-7, Steven G. Kargl wrote:

(snip, I wrote)

> > As well as I remember it, Fortran has been ignoring integer
> > overflow since long before I started learning it in 1972.
> > Long enough for programmers to depend on it.

> Fortran compilers of yesteryears may have ignored it, but
> the Fortran standards did not:

> Fortran 77, page 6-20

> Any arithmetic operation whose result is not mathematically defined
> is prohibited in the execution of an executable program.

> Fortran 66, page 12

> No element may evaluated whose vlue is mathematically defined.

Yes. Well, the standard also allows for any integer radix greater than 2,
and different representations for signed values.

So, the values on overflow are system dependent.
Only when one knows the characteristics of the system can they
use the overflow results. But often enough, one does know.
Not quite as convenient for portable programs, though.

[Thomas Koenig]

gah4 <ga...@u.washington.edu> schrieb:

> So, the values on overflow are system dependent.

That is not correct. Overflow is an error, and what happens
is system dependent.

> Only when one knows the characteristics of the system can they
> use the overflow results.

If the behavior is documented to work, yes. If it is _not_
documented, then ths may break on the next compiler upgrade
(as it did, here).

This was actually discovered in nf, of the Polyhedron testsuite.
Further investigation showed that the routine in question was
already broken in gcc 12, just in a different and not-so-noticable
way. That's when the decision was made to not try and fix it,
but rather document.

> But often enough, one does know.

... or thinks one knows. If it's not documented...

What did the old compiler documentation say about this?

> Not quite as convenient for portable programs, though.

Use extended arithmetic (which is available these days) and check.

[Steven G. Kargl]

On Thu, 11 May 2023 20:55:06 -0700, gah4 wrote:

> On Thursday, May 11, 2023 at 7:08:35 PM UTC-7, Steven G. Kargl wrote:
>
> (snip, I wrote)
>> > As well as I remember it, Fortran has been ignoring integer
>> > overflow since long before I started learning it in 1972.
>> > Long enough for programmers to depend on it.
>
>> Fortran compilers of yesteryears may have ignored it, but
>> the Fortran standards did not:
>
>> Fortran 77, page 6-20
>
>> Any arithmetic operation whose result is not mathematically defined
>> is prohibited in the execution of an executable program.
>
>> Fortran 66, page 12
>
>> No element may evaluated whose vlue is mathematically defined.
>
> Yes. Well, the standard also allows for any integer radix greater than 2,
> and different representations for signed values.

Non sequitur. Can you tell me how a radix 1 integer works?

> So, the values on overflow are system dependent.

It's prohibited.

> Only when one knows the characteristics of the system can they
> use the overflow results.

It's prohibited.

> But often enough, one does know.
> Not quite as convenient for portable programs, though.

It's prohibited.

The user got lucky.

--
steve

[gah4]

On Thursday, May 11, 2023 at 10:55:09 PM UTC-7, Steven G. Kargl wrote:
> On Thu, 11 May 2023 20:55:06 -0700, gah4 wrote:

(snip)

> Non sequitur. Can you tell me how a radix 1 integer works?

That is why it is: "where r is an integer exceeding one,"

> > So, the values on overflow are system dependent.
> It's prohibited.

> > Only when one knows the characteristics of the system can they
> > use the overflow results.
> It's prohibited.

> > But often enough, one does know.
> > Not quite as convenient for portable programs, though.

> It's prohibited.

> The user got lucky.

Some people were lucky for 65 years.