On 18/06/2021 01:46, MitchAlsup wrote:
> On Thursday, June 17, 2021 at 2:24:05 PM UTC-5, David Brown wrote:
>> On 17/06/2021 20:22, MitchAlsup wrote:
>>> On Thursday, June 17, 2021 at 12:38:33 PM UTC-5, Tim Rentsch wrote:
>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>
>>>>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
>>>>>
>>>>>> A common source of
>>>>>> errors is implicit type conversions in C, for instance.
>>>>>
>>>>> The integral promotions from signed to unsigned of the
>>>>> same size are the worst.
>>>>>
>>>>> int a = -3;
>>>>> unsigned int b = 2;
>>>>> if (a > b)
>>>>> printf ("You expected this to happen, right?\n");
>>>>
>>>> The C standard uses the term "integer promotions" rather than
>>>> "integral promotions", but in any case what is going on here
>>>> falls under the heading of "usual arithmetic conversions",
>>>> not "integer promotions". (Integer promotions are things
>>>> like turning a 'short' into an 'int'.)
>>> <
>>> What causes the supersize is that programmers are not taught
>>> unsigned has a lower surprise factor than integer.
> <
>> unsigned types in C don't have "lower surprise factor" than signed
>> types. They have slightly /different/ surprise factors. If you want to
>> program in C, you should learn how the signed and unsigned integer types
>> work, alone and together, and code accordingly.
> <
> While they do have different surprise factors, the unsigned variety is lower
> because when signed an unsigned are mixed, the unsigned takes precedent.

That is only the case for types of size "int" and bigger. Unsigned
types smaller than "int" promote to /signed/ int. I am not a fan of the
way this works in C and C++, but I think it is a good idea to know the
rules rather than live by generalisations that are not always correct.

> <
> And as I have stated many times: the only time I EVER use a signed type
> is when at some point it has to contain a negative value. Then, again, if
> it always contains a negative value (never positive) I STILL use unsigned
> and subtract rather than add.

And the only time you use a screwdriver is if hammering the screw in fails?

Signed and unsigned types have their differences, advantages and
disadvantages. If you want to program in C or C++ (or other languages
with the distinction), it pays to learn how the types work, use the
appropriate type for the task, and be careful when mixing them. For
some tasks, unsigned types will naturally be more common - but going out
of your way to avoid signed types because /you/ find them "surprising"
will surprise anyone else looking at the code.

> <
> About the only time I use a signed integer type is when interfacing with a
> library routine which has parameters or result defined as signed.
>>
>> There is a lot of value in using good static warning tools - enabling
>> "-Wsign-compare -Wsign-conversion" in gcc will give you warnings on
>> these things if you don't use explicit casts. You choose your own
>> balance between reduced risk of errors at the cost of additional effort
>> (such as casts) when you need to mixed signedness and know it is safe.
>>
>> One problem with a lot of C teaching is that it usually fails to teach
>> about tools that can make programming easier and safer. Another is that
>> if they teach the details of integer types at all, they do so with
>> invalid and unhelpful generalisations like "unsigned types are better
>> because overflow is defined and they are therefore safe".
>>> <
>>> But consider::
>>> <
>>> int64_t a = -3;
>>> uint64_t b = 0xfffffffffffffffd;
>>> if( a == b )
>>> printf ("You expected this to happen, right?\n");
>>>

On Friday, June 18, 2021 at 1:30:05 AM UTC-5, Thomas Koenig wrote:
> Ivan Godard <iv...@millcomputing.com> schrieb:
> > The warnings are necessary, but still annoying:
> > for (int i = 0; i < arr.size(); i++)
> Why chose arr.size() as unsigned?
<
Because it never can deliver a negative number !
>
> As long as the types are long enough that overflow is not
> an issue (as should be the case with 64-bit types), signed
> has far nicer properties.

David Brown <david.brown@hesbynett.no> schrieb:

> I disagree somewhat on saying "signed has far nicer properties", just as
> I disagree with people who say "unsigned" are "safer" or better defined.

The main reason why I try to use unsigned only where possible is loops.

With signed integers, it is easy to write a loop from a to b
which gets executed zero times if a > b, as in

for (i=a ; i<b, i++)

For unsigned... hm.

On 18/06/2021 18:39, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>
>> I disagree somewhat on saying "signed has far nicer properties", just as
>> I disagree with people who say "unsigned" are "safer" or better defined.
>
> The main reason why I try to use unsigned only where possible is loops.
>
> With signed integers, it is easy to write a loop from a to b
> which gets executed zero times if a > b, as in
>
> for (i=a ; i<b, i++)
>
> For unsigned... hm.
>

I prefer to know what "a" and "b" are before writing the loop, and
whether (a > b) might hold.

If you write your code assuming (a <= b), but in fact (a > b), then it
doesn't matter if you use signed or unsigned types - your code is
broken. And if the assumption /does/ hold, then it doesn't matter
whether your types are signed or unsigned either.

In general, if it actually matters whether you have signed or unsigned
types (assuming they cover the ranges you need), then your code is
probably wrong. Unsigned overflow is almost almost an error regardless
of how well defined it is in the language.

David Brown <david.brown@hesbynett.no> schrieb:
> On 18/06/2021 18:39, Thomas Koenig wrote:
>> David Brown <david.brown@hesbynett.no> schrieb:
>>
>>> I disagree somewhat on saying "signed has far nicer properties", just as
>>> I disagree with people who say "unsigned" are "safer" or better defined.
>>
>> The main reason why I try to use unsigned only where possible is loops.
>>
>> With signed integers, it is easy to write a loop from a to b
>> which gets executed zero times if a > b, as in
>>
>> for (i=a ; i<b, i++)
>>
>> For unsigned... hm.
>>
>
> I prefer to know what "a" and "b" are before writing the loop, and
> whether (a > b) might hold.
>
> If you write your code assuming (a <= b), but in fact (a > b), then it
> doesn't matter if you use signed or unsigned types - your code is
> broken. And if the assumption /does/ hold, then it doesn't matter
> whether your types are signed or unsigned either.

I have use, from time to time, for arrays with negative offsets
(I guess Fortran spoiled me there). Looping over such an
array with an unsigned index would be... interesting.

The other thing that I like are zero-sized arrays which take
no special handling, they just work.

Again, hard to do with unsigned integers.

That's what I like about potential zero-trip loops with signed
types - they get this right. Fortran had this since F77,
C earlier with its test in the for loop before execution as well.
I'd have to look up the earlier definition of Algol etc to see
how far this goes back.

"Do nothing it there is nothing to do" seems like a pretty good
paradigm to me, and that is just so much harder with unsigned
integers.

How would an unsigned loop looping from 0xff...ff to 1 look like?

They have their place - sometimes you want modulo 2^n arithmetic,
and sometimes 0 - 1 should really be 2^n-1, but not always.

On 6/18/2021 1:54 PM, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>> On 18/06/2021 18:39, Thomas Koenig wrote:
>>> David Brown <david.brown@hesbynett.no> schrieb:
>>>
>>>> I disagree somewhat on saying "signed has far nicer properties", just as
>>>> I disagree with people who say "unsigned" are "safer" or better defined.
>>>
>>> The main reason why I try to use unsigned only where possible is loops.
>>>
>>> With signed integers, it is easy to write a loop from a to b
>>> which gets executed zero times if a > b, as in
>>>
>>> for (i=a ; i<b, i++)
>>>
>>> For unsigned... hm.
>>>
>>
>> I prefer to know what "a" and "b" are before writing the loop, and
>> whether (a > b) might hold.
>>
>> If you write your code assuming (a <= b), but in fact (a > b), then it
>> doesn't matter if you use signed or unsigned types - your code is
>> broken. And if the assumption /does/ hold, then it doesn't matter
>> whether your types are signed or unsigned either.
>
> I have use, from time to time, for arrays with negative offsets
> (I guess Fortran spoiled me there). Looping over such an
> array with an unsigned index would be... interesting.
>
> The other thing that I like are zero-sized arrays which take
> no special handling, they just work.
>
> Again, hard to do with unsigned integers.
>
> That's what I like about potential zero-trip loops with signed
> types - they get this right. Fortran had this since F77,
> C earlier with its test in the for loop before execution as well.
> I'd have to look up the earlier definition of Algol etc to see
> how far this goes back.
>
> "Do nothing it there is nothing to do" seems like a pretty good
> paradigm to me, and that is just so much harder with unsigned
> integers.
>
> How would an unsigned loop looping from 0xff...ff to 1 look like?
>
> They have their place - sometimes you want modulo 2^n arithmetic,
> and sometimes 0 - 1 should really be 2^n-1, but not always.
>

An array with negative indices wouldn't use size() as in my example;
you'd need
someType arr[-3..17];
for (int i = arr.lwb(), i <= arr.upb(), ++i)

Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>> On 18/06/2021 18:39, Thomas Koenig wrote:
>>> David Brown <david.brown@hesbynett.no> schrieb:
>>>
>>>> I disagree somewhat on saying "signed has far nicer properties", just as
>>>> I disagree with people who say "unsigned" are "safer" or better defined.
>>>
>>> The main reason why I try to use unsigned only where possible is loops.
>>>
>>> With signed integers, it is easy to write a loop from a to b
>>> which gets executed zero times if a > b, as in
>>>
>>> for (i=a ; i<b, i++)
>>>
>>> For unsigned... hm.
>>>
>>
>> I prefer to know what "a" and "b" are before writing the loop, and
>> whether (a > b) might hold.
>>
>> If you write your code assuming (a <= b), but in fact (a > b), then it
>> doesn't matter if you use signed or unsigned types - your code is
>> broken. And if the assumption /does/ hold, then it doesn't matter
>> whether your types are signed or unsigned either.
>
> I have use, from time to time, for arrays with negative offsets
> (I guess Fortran spoiled me there). Looping over such an
> array with an unsigned index would be... interesting.
>
> The other thing that I like are zero-sized arrays which take
> no special handling, they just work.
>
> Again, hard to do with unsigned integers.

for (size_t i = 0; i < arr.size; i++) {}

With arr.size == 0 all compilers will give you zero iterations of the
loop, what is the issue?

The only slightly complicated situation with unsigned is when I need to
count down to zero, i.e. do something to arr[n-1], arr[n-2],...arr[1],
arr[0.

Here it is easy but wrong to write the natural¨

for (size_t i = arr.size-1; i >= 0; i--) { do something with arr[i] }

since a size_t can never become negative so this is an infinite loop.

The alternatives are slighly more complicated:

for (size_t i = arr.size; i > 0; i--) { do something with arr[i-1] }

or

for (size_t i = arr.size; i-- > 0; /* nothing here! */ ) {
do something with arr[i]
}

I.e. remove the traditional i-- from the end of the for loop and instead
integrate it with the loop end test.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> David Brown <david.brown@hesbynett.no> schrieb:
>>> On 18/06/2021 18:39, Thomas Koenig wrote:
>>>> David Brown <david.brown@hesbynett.no> schrieb:
>>>>
>>>>> I disagree somewhat on saying "signed has far nicer properties", just as
>>>>> I disagree with people who say "unsigned" are "safer" or better defined.
>>>>
>>>> The main reason why I try to use unsigned only where possible is loops.
>>>>
>>>> With signed integers, it is easy to write a loop from a to b
>>>> which gets executed zero times if a > b, as in
>>>>
>>>> for (i=a ; i<b, i++)
>>>>
>>>> For unsigned... hm.
>>>>
>>>
>>> I prefer to know what "a" and "b" are before writing the loop, and
>>> whether (a > b) might hold.
>>>
>>> If you write your code assuming (a <= b), but in fact (a > b), then it
>>> doesn't matter if you use signed or unsigned types - your code is
>>> broken. And if the assumption /does/ hold, then it doesn't matter
>>> whether your types are signed or unsigned either.
>>
>> I have use, from time to time, for arrays with negative offsets
>> (I guess Fortran spoiled me there). Looping over such an
>> array with an unsigned index would be... interesting.
>>
>> The other thing that I like are zero-sized arrays which take
>> no special handling, they just work.
>>
>> Again, hard to do with unsigned integers.
>
> for (size_t i = 0; i < arr.size; i++) {}
>
> With arr.size == 0 all compilers will give you zero iterations of the
> loop, what is the issue?

There isn't an issue for that particular use case. However,
loops with unsigned variables are problematic if you want
nothing done for b < a when you write

for (i=a; i<b; i++)

and b could have a wraparound.

An issue with optimization is that it is much harder for a compiler
to handle loop with unsigned values, it is often impossible to
prove that they terminate.

And, of course, writing a traditional Fortran DO loop with unsigned
arithmetic would be highly problematic at least :-)

On Sunday, June 20, 2021 at 2:30:24 PM UTC-5, Thomas Koenig wrote:
> Terje Mathisen <terje.m...@tmsw.no> schrieb:
> > Thomas Koenig wrote:
> >> David Brown <david...@hesbynett.no> schrieb:
> >>> On 18/06/2021 18:39, Thomas Koenig wrote:
> >>>> David Brown <david...@hesbynett.no> schrieb:
> >>>>
> >>>>> I disagree somewhat on saying "signed has far nicer properties", just as
> >>>>> I disagree with people who say "unsigned" are "safer" or better defined.
> >>>>
> >>>> The main reason why I try to use unsigned only where possible is loops.
> >>>>
> >>>> With signed integers, it is easy to write a loop from a to b
> >>>> which gets executed zero times if a > b, as in
> >>>>
> >>>> for (i=a ; i<b, i++)
> >>>>
> >>>> For unsigned... hm.
> >>>>
> >>>
> >>> I prefer to know what "a" and "b" are before writing the loop, and
> >>> whether (a > b) might hold.
> >>>
> >>> If you write your code assuming (a <= b), but in fact (a > b), then it
> >>> doesn't matter if you use signed or unsigned types - your code is
> >>> broken. And if the assumption /does/ hold, then it doesn't matter
> >>> whether your types are signed or unsigned either.
> >>
> >> I have use, from time to time, for arrays with negative offsets
> >> (I guess Fortran spoiled me there). Looping over such an
> >> array with an unsigned index would be... interesting.
> >>
> >> The other thing that I like are zero-sized arrays which take
> >> no special handling, they just work.
> >>
> >> Again, hard to do with unsigned integers.
> >
> > for (size_t i = 0; i < arr.size; i++) {}
> >
> > With arr.size == 0 all compilers will give you zero iterations of the
> > loop, what is the issue?
> There isn't an issue for that particular use case. However,
> loops with unsigned variables are problematic if you want
> nothing done for b < a when you write
>
> for (i=a; i<b; i++)
>
> and b could have a wraparound.
>
> An issue with optimization is that it is much harder for a compiler
> to handle loop with unsigned values, it is often impossible to
> prove that they terminate.
>
> And, of course, writing a traditional Fortran DO loop with unsigned
> arithmetic would be highly problematic at least :-)
<
FORTRAN DO loops can convert the DO loop range in to a counted number
loop passes and avoid the problem.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Sunday, June 20, 2021 at 2:30:24 PM UTC-5, Thomas Koenig wrote:

>> loops with unsigned variables are problematic if you want
>> nothing done for b < a when you write
>>
>> for (i=a; i<b; i++)
>>
>> and b could have a wraparound.
>>
>> An issue with optimization is that it is much harder for a compiler
>> to handle loop with unsigned values, it is often impossible to
>> prove that they terminate.
>>
>> And, of course, writing a traditional Fortran DO loop with unsigned
>> arithmetic would be highly problematic at least :-)
><
> FORTRAN DO loops can convert the DO loop range in to a counted number
> loop passes and avoid the problem.

This is indeed how the loop count is defined.

If you have a loop

DO I=m1,m2,m3

then (clause 11.1.7.4.1, p. 3) "The iteration count is established
and is the value of the expression (m2 − m1 + m3 )/m3 , unless
that value is negative, in which case the iteration count is 0."
Note 1 (non-normative) stating

The iteration count is zero whenever:
m1 > m2 and m3 > 0, or
m1 < m2 and m3 < 0.

If you do this with signed integers, all is fine. If you introduce
unsigned integers, you would have to redfine things because
(m2 - m1 + m3)/m3 can no longer be negative, and defining
what the iteratiion cound should be for

do i=1,2,unsigned(-1)

could become interesting. "Can of worms" only just starts describing
the issues...

On 20/06/2021 21:04, Terje Mathisen wrote:
> Thomas Koenig wrote:
>> David Brown <david.brown@hesbynett.no> schrieb:
>>> On 18/06/2021 18:39, Thomas Koenig wrote:
>>>> David Brown <david.brown@hesbynett.no> schrieb:
>>>>
>>>>> I disagree somewhat on saying "signed has far nicer properties",
>>>>> just as
>>>>> I disagree with people who say "unsigned" are "safer" or better
>>>>> defined.
>>>>
>>>> The main reason why I try to use unsigned only where possible is loops.
>>>>
>>>> With signed integers, it is easy to write a loop from a to b
>>>> which gets executed zero times if a > b, as in
>>>>
>>>>    for (i=a ; i<b, i++)
>>>>
>>>> For unsigned... hm.
>>>>
>>>
>>> I prefer to know what "a" and "b" are before writing the loop, and
>>> whether (a > b) might hold.
>>>
>>> If you write your code assuming (a <= b), but in fact (a > b), then it
>>> doesn't matter if you use signed or unsigned types - your code is
>>> broken.  And if the assumption /does/ hold, then it doesn't matter
>>> whether your types are signed or unsigned either.
>>
>> I have use, from time to time, for arrays with negative offsets
>> (I guess Fortran spoiled me there).  Looping over such an
>> array with an unsigned index would be... interesting.
>>
>> The other thing that I like are zero-sized arrays which take
>> no special handling, they just work.
>>
>> Again, hard to do with unsigned integers.
>
> for (size_t i = 0; i < arr.size; i++) {}
>
> With arr.size == 0 all compilers will give you zero iterations of the
> loop, what is the issue?
>
> The only slightly complicated situation with unsigned is when I need to
> count down to zero, i.e. do something to arr[n-1], arr[n-2],...arr[1],
> arr[0.
>
> Here it is easy but wrong to write the natural¨
>
>  for (size_t i = arr.size-1; i >= 0; i--) { do something with arr[i] }
>
> since a size_t can never become negative so this is an infinite loop.
>
> The alternatives are slighly more complicated:
>
>   for (size_t i = arr.size; i > 0; i--) { do something with arr[i-1] }
>
> or
>
>   for (size_t i = arr.size; i-- > 0; /* nothing here! */ ) {
>     do something with arr[i]
>   }
>
> I.e. remove the traditional i-- from the end of the for loop and instead
> integrate it with the loop end test.
>
> Terje
>

Or you can use the ranged for in C++ :

Iterate forward:

void foo2(void) {
for (auto& a : arr) {
a++;
}
}

Iterate backwards (using <ranges> from C++20 or boost libraries) :

void bar1(void) {
for (auto& a : arr | std::views::reverse) {
a++;
}
}

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> MitchAlsup wrote:
>
>>> [...]
>>
>> This brings to mind that the whole concept of arithmetic exceptions is
>> fundamentally flawed.
>> It is not the arithmetic that should be checked for out-of-range values
>> it is the depositing of values into containers that should be checked.
>
> I agree:
>
> It is my strong and not so humble opinion that a cpu/program/language
> should always be free to deliver the best result it can, i.e. even if
> an intermediate results would overflow/trap on most other CPUs.
>
> If the final result delivered is in range, and mathematically correct,
> then use it, otherwise trap at that point.
>
> It is typically more prevalent on FP where some architectures can
> deliver results that are closer to the mathematical definition than
> others (long double intermediates etc), but the recent uint16_t
> example shows that this can be an issue for integer ops as well.

First let me see if I understand you. If we have code like this

some_type a, b, c;

...

some_type x = a + b - c;

do you mean that the code could work reliably on some systems and
fail reliably on other systems? (The "reliably" here means no
undefined behavior in either case.)

Also, if we have code like this

some_type a, b, c;

...

some_type x = a + b - c;

then the result could be different than if the code were written
instead as follows

some_type a, b, c;

...

some_type a_plus_b = a + b;
some_type x = a_plus_b - c;

In the above 'some_type' is meant to be any integer type
or any real floating point type. (I am curious to know
if you also meant to include complex floating point types,
but that is very much a secondary question.) Also the
question is meant to include other arithmetic operations
such as *, /, and %.

Have I understood you correctly? If so, is there something
important that I missed? If not, could you explain what you
do mean?

> First let me see if I understand you. If we have code like this
>
> some_type a, b, c;
>
> ...
>
> some_type x = a + b - c;
>
> do you mean that the code could work reliably on some systems and
> fail reliably on other systems? (The "reliably" here means no
> undefined behavior in either case.)

Take `some_type` to be some kind of multiprecision integer. Then yes,
I think it makes sense to reliably return the right result when there's
enough memory to hold those integers and to trap reliably when we run
out of memory during the computation.

Stefan

On Friday, June 25, 2021 at 10:53:44 PM UTC-5, Tim Rentsch wrote:
> Terje Mathisen <terje.m...@tmsw.no> writes:
>
> > MitchAlsup wrote:
> >
> >>> [...]
> >>
> >> This brings to mind that the whole concept of arithmetic exceptions is
> >> fundamentally flawed.
> >> It is not the arithmetic that should be checked for out-of-range values
> >> it is the depositing of values into containers that should be checked.
> >
> > I agree:
> >
> > It is my strong and not so humble opinion that a cpu/program/language
> > should always be free to deliver the best result it can, i.e. even if
> > an intermediate results would overflow/trap on most other CPUs.
> >
> > If the final result delivered is in range, and mathematically correct,
> > then use it, otherwise trap at that point.
> >
> > It is typically more prevalent on FP where some architectures can
> > deliver results that are closer to the mathematical definition than
> > others (long double intermediates etc), but the recent uint16_t
> > example shows that this can be an issue for integer ops as well.
>
> First let me see if I understand you. If we have code like this
>
> some_type a, b, c;
>
> ...
>
> some_type x = a + b - c;
>
> do you mean that the code could work reliably on some systems and
> fail reliably on other systems? (The "reliably" here means no
> undefined behavior in either case.)
>
> Also, if we have code like this
>
> some_type a, b, c;
>
> ...
>
> some_type x = a + b - c;
>
> then the result could be different than if the code were written
> instead as follows
>
> some_type a, b, c;
>
> ...
>
> some_type a_plus_b = a + b;
> some_type x = a_plus_b - c;
<
FORTRAN allows for::
<
some_type x = (a+b)-c;
<
Parenthesis have to be obeyed. The # define in C pretty much made
this FORTRAN convention unworkable in C derived languages.
>
> In the above 'some_type' is meant to be any integer type
> or any real floating point type. (I am curious to know
> if you also meant to include complex floating point types,
> but that is very much a secondary question.) Also the
> question is meant to include other arithmetic operations
> such as *, /, and %.
>
> Have I understood you correctly? If so, is there something
> important that I missed? If not, could you explain what you
> do mean?

MitchAlsup <MitchAlsup@aol.com> writes:

> On Friday, June 25, 2021 at 10:53:44 PM UTC-5, Tim Rentsch wrote:
>
>> Terje Mathisen <terje.m...@tmsw.no> writes:
>>
>>> MitchAlsup wrote:
>>>
>>>>> [...]
>>>>
>>>> This brings to mind that the whole concept of arithmetic exceptions is
>>>> fundamentally flawed.
>>>> It is not the arithmetic that should be checked for out-of-range values
>>>> it is the depositing of values into containers that should be checked.
>>>
>>> I agree:
>>>
>>> It is my strong and not so humble opinion that a cpu/program/language
>>> should always be free to deliver the best result it can, i.e. even if
>>> an intermediate results would overflow/trap on most other CPUs.
>>>
>>> If the final result delivered is in range, and mathematically correct,
>>> then use it, otherwise trap at that point.
>>>
>>> It is typically more prevalent on FP where some architectures can
>>> deliver results that are closer to the mathematical definition than
>>> others (long double intermediates etc), but the recent uint16_t
>>> example shows that this can be an issue for integer ops as well.
>>
>> First let me see if I understand you. If we have code like this
>>
>> some_type a, b, c;
>>
>> ...
>>
>> some_type x = a + b - c;
>>
>> do you mean that the code could work reliably on some systems and
>> fail reliably on other systems? (The "reliably" here means no
>> undefined behavior in either case.)
>>
>> Also, if we have code like this
>>
>> some_type a, b, c;
>>
>> ...
>>
>> some_type x = a + b - c;
>>
>> then the result could be different than if the code were written
>> instead as follows
>>
>> some_type a, b, c;
>>
>> ...
>>
>> some_type a_plus_b = a + b;
>> some_type x = a_plus_b - c;
>
> FORTRAN allows for::
> some_type x = (a+b)-c;
> Parenthesis have to be obeyed. [...]

Fine, but that's not what I'm asking about, which is
standard arithmetic types in a C-like language.