On 18/10/2021 14:45, Michael S wrote:
> On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:

>> Back here in the real world, if programmers stopped writing silly code
>> then there would be a lot fewer software problems to go around.
>
> Don't be silly.
> The best solution does not involve magic.
> Something like that will do:
>
> Signed overflow is implementation-defined, but in constrained way.
> Possible options are
> 1. two-complement wrap-around
> 2. trap
> 3. saturation
> 4. one-complement wrap-around, if there exist a member of committee that care about it
> Implementation has to specify the chosen option clearly in documentation. It is allowed to select an option
> with special flag. It is not allowed to make option dependent on optimization settings.
> If the chosen option is trap and overflow happens in intermediate result of complex expression, but not in the final result than it's it's legal for trap to be intermittent and dependent on ether optimization level or phase of the moon, but not both.
>

That is not an attitude I would accept in a programmer working for me.
(I'd accept - and correct - ignorance. That's a different matter.)

I will happily accept a trapping option as a temporary choice while
chasing a bug. I will happily accept specific behaviour, coded
/correctly/, in cases where specific behaviour is appropriate and
correct - in some algorithms, saturation is the desired behaviour, and
in a few cases modulo behaviour is the model you want. These can be
written correctly in C without any undefined behaviour, special flags,
limited compilers, sacrificing of black cockerels, or whatever other
effort you make in order to make incorrect code give the results you want.

But anyone who tells me that their own particular interpretation of what
happens on signed integer overflow is "the one right answer", "the
obvious choice", "the most efficient choice", "what C used to do", or
anything on that line - that person is going to have a hard time trying
to justify themselves. And if they tell me "it worked when I tried it",
I'll know their code reviews will take a lot longer.

Coding is, for the most part, a matter of defining and calling functions
(as a general term, this includes operators). Every function has a
pre-condition that the caller ensures is true before calling the
function, and a post-condition that the function ensures is true before
returning. The function can - and generally must - assume the
pre-condition is true at the start of the function, just as the caller
can assume the post-condition is true at the return.

Thus if you give the function appropriate inputs, you can expect the
desired output. If you give it invalid inputs, you can't have any
reasonable expectations about what comes out. Garbage in, garbage out.
It is the programmer's job to ensure that he or she does not put
garbage in.

And in the case of signed integer arithmetic, it is the programmer's job
to ensure that the input to expressions will not cause an overflow. It
is /not/ the compiler's job to ensure that if garbage is put in, the
garbage that comes out should always smell of roses.

You can argue until you are blue in the face that you think signed
integer arithmetic overflow /should/ be defined, whether you have a
particular idea for how it should be defined, or you just want it to do
"something". There are languages where it /is/ defined. In C, it is
/not/ defined. Accept that, or use a different language. End of story.

Michael S <already5chosen@yahoo.com> writes:

[..considering code examples..]

if ((x < 1) || (x > 3)) __builtin_unreachable();
y = z / x;

[..or alternative..]

if (x == 1) {
y = 1;
} else if (x == 2) {
y = z / 2;
} else {
y = z / 3;
}

[..(end code examples)..]

> I'd very much prefer
> y = x > 1 && x < 4 ? z/x : z;

+1

> Depending on distribution of x, it can be either faster or slower
> or the same as [the first example], but is fully-defined, does not
> depend on gcc extensions and, IMHO, is easier to grasp.

+1

(Linguistic nit: no hyphen between "fully" and "defined". In
most cases there is no hyphen between an adverb and a following
adjective.)

On Monday, October 18, 2021 at 4:24:00 PM UTC+3, David Brown wrote:
> On 18/10/2021 14:45, Michael S wrote:
> > On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
>
> >> Back here in the real world, if programmers stopped writing silly code
> >> then there would be a lot fewer software problems to go around.
> >
> > Don't be silly.
> > The best solution does not involve magic.
> > Something like that will do:
> >
> > Signed overflow is implementation-defined, but in constrained way.
> > Possible options are
> > 1. two-complement wrap-around
> > 2. trap
> > 3. saturation
> > 4. one-complement wrap-around, if there exist a member of committee that care about it
> > Implementation has to specify the chosen option clearly in documentation. It is allowed to select an option
> > with special flag. It is not allowed to make option dependent on optimization settings.
> > If the chosen option is trap and overflow happens in intermediate result of complex expression, but not in the final result than it's it's legal for trap to be intermittent and dependent on ether optimization level or phase of the moon, but not both.
> >
> That is not an attitude I would accept in a programmer working for me.
> (I'd accept - and correct - ignorance. That's a different matter.)
>
> I will happily accept a trapping option as a temporary choice while
> chasing a bug. I will happily accept specific behaviour, coded
> /correctly/, in cases where specific behaviour is appropriate and
> correct - in some algorithms, saturation is the desired behaviour, and
> in a few cases modulo behaviour is the model you want. These can be
> written correctly in C without any undefined behaviour, special flags,

First, it is true that modulo is what I really want, but I leave other options open.

Second, I don't think that modulo behavior can be easily achieved in legalistic dialect of C.
In "solutions" that I had seen there are rat hole near assignment of certain unsigned rvalues
to signed lvalue and even bigger hole in handling of multiplication.

Third, even if it's possible, there are other dimensions apart from legalism.
One is aesthetic (it's ugly) and other is ergonomic (it's error prone).

> limited compilers, sacrificing of black cockerels, or whatever other
> effort you make in order to make incorrect code give the results you want.
>
> But anyone who tells me that their own particular interpretation of what
> happens on signed integer overflow is "the one right answer", "the
> obvious choice", "the most efficient choice", "what C used to do", or
> anything on that line - that person is going to have a hard time trying
> to justify themselves. And if they tell me "it worked when I tried it",
> I'll know their code reviews will take a lot longer.
>
> Coding is, for the most part, a matter of defining and calling functions
> (as a general term, this includes operators). Every function has a
> pre-condition that the caller ensures is true before calling the
> function, and a post-condition that the function ensures is true before
> returning. The function can - and generally must - assume the
> pre-condition is true at the start of the function, just as the caller
> can assume the post-condition is true at the return.
>
> Thus if you give the function appropriate inputs, you can expect the
> desired output. If you give it invalid inputs, you can't have any
> reasonable expectations about what comes out. Garbage in, garbage out.
> It is the programmer's job to ensure that he or she does not put
> garbage in.
>
> And in the case of signed integer arithmetic, it is the programmer's job
> to ensure that the input to expressions will not cause an overflow. It
> is /not/ the compiler's job to ensure that if garbage is put in, the
> garbage that comes out should always smell of roses.
>

From a person that never complains about C Standard definition of "unsigned"
that sounds more than a bit hypocritical.

>
> You can argue until you are blue in the face that you think signed
> integer arithmetic overflow /should/ be defined, whether you have a
> particular idea for how it should be defined, or you just want it to do
> "something". There are languages where it /is/ defined. In C, it is
> /not/ defined. Accept that, or use a different language. End of story.

I am not sure.
It can be fixed in the future. The pressure is applied all the time and by far more influential people than myself.

Michael S <already5chosen@yahoo.com> writes:

>> [..sarcastic comments regarding signed overflow..]

> Don't be silly.
> The best solution does not involve magic.
> Something like that will do:
>
> Signed overflow is implementation-defined, but in constrained way.
> Possible options are
> 1. two-complement wrap-around
> 2. trap
> 3. saturation
> 4. one-complement wrap-around, if there exist a member of
> committee that care about it
>
> Implementation has to specify the chosen option clearly in
> documentation. It is allowed to select an option with special
> flag. It is not allowed to make option dependent on optimization
> settings. If the chosen option is trap and overflow happens in
> intermediate result of complex expression, but not in the final
> result than it's it's legal for trap to be intermittent and
> dependent on ether optimization level or phase of the moon, but
> not both.

My sense is this idea is not much better than how things are
now. I would like to see the decision be under control of
the source code, perhaps by means of a #pragma:

#pragma STDC SIGNED_OVERFLOW WRAP
#pragma STDC SIGNED_OVERFLOW TRAP
#pragma STDC SIGNED_OVERFLOW SATURATE
#pragma STDC SIGNED_OVERFLOW UNDEFINED
(..others?..)

If it's important, implementations might be allowed not to
implement some or all of these choices; but if they don't then
they must at least check the #pragma line for legality and fail
the compilation if they cannot accommodate the choice indicated
(or if the #pragma STDC doesn't scan for some reason).

On 18/10/2021 15:21, Michael S wrote:
> On Monday, October 18, 2021 at 4:02:21 PM UTC+3, David Brown wrote:
>> On 18/10/2021 14:23, Michael S wrote:
>>> On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
>>>> On 18/10/2021 01:47, Victor Yodaiken wrote:
>>>>> On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
>>
>>>>>> If I tell the compiler "assume x is between 1 and 3", what do you think
>>>>>> should happen if it is /not/ in that range?
>>>>>>
>>>>>> Perhaps I have code:
>>>>>>
>>>>>> if ((x < 1) || (x > 3)) __builtin_unreachable();
>>>>>> y = z / x;
>>>>>>
>>
>>>
>>> I'd very much prefer
>>> y = x > 1 && x < 4 ? z/x : z;
>>> Depending on distribution of x, it can be either faster or slower or the same as your variant, but is fully-defined, does not depend on gcc extensions and, IMHO, is easier to grasp.
>>>
>> A quick test will show you that my version is faster -
>
> So, do it.
> I can't test it myself, because right now I have no HW on my table on which division is much slower than branch mispredict.
> Don't forget to test a distribution in which x==1 occures much more often than 2 and 3.

Use <https://godbolt.org>.

Of course, on your particular hardware the less efficient code might not
translate into a difference in real execution speed - and execution
speed is not always important. On my targets - small, relatively simple
processors - extra instructions means extra time.

>
>> a compiler will
>> either make use of the extra information in order to give more efficient
>> results, or it will ignore the test entirely and give you the same as
>> plain "y = z / x;". Your version (after correcting to "x >= 1"),
>
> No need to correct anything. My version is correct as written.
>

Sorry, yes, I see what you mean. However, the whole point of the
exercise is /not/ manual micro-optimisations. It is to give the
compiler more information, and let the /compiler/ optimise. Of course
in this particular example it would be possible to write manual
optimisation, in which case it would not be done the way you did it.
Imagine it was real code, and you had "x_min" and "x_max", defined as
constants somewhere far off in a header, rather than 1 and 3.

>> on the
>> other hand, /forces/ the compiler to make the comparison, and any
>> optimisations it might have been able to apply to the "z/x" bit could be
>> applied in my version.
>>
>> Your version is not fully defined for all x - it is undefined if x is 0.
>
> Wrong. For x=0 it returns z.

Yes, again I read a little too quickly. Yes it is defined - it gives a
meaningless result for invalid input. That does not matter, there is no
need to give any kind of result for invalid input.

>
>> It /is/ fully defined on the specified input range with x from 1 to 3,
>> but so is mine. Being defined for values of x that cannot occur is of
>> no benefit whatsoever.
>>
>> Your version does not depend on a gcc extension, that is certainly true
>> - there is no good portable way to give the compiler such extra
>> information (that was my point).
>>
>> Easier to grasp is, of course, in the eye of the reader.
>>
>> In practice, I have such tests wrapped in a macro, and thus write :
>>
>> assume((x >= 1) && (x <= 3));
>> y = z / x;
>> If the compiler can tell at compile-time that the assumption is wrong,
>> it gives me an error message. If I want to check it at run-time, I set
>> a pre-processor symbol (like DEBUG for standard "assert") to choose such
>> checking.

On 18/10/2021 14:59, clamky@hotmail.com wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
>> On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
>>> On 18/10/2021 01:47, Victor Yodaiken wrote:
>>>> On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
>>>>> On 17/10/2021 16:40, Victor Yodaiken wrote:
>>>>>> On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
>>>>>>
>
> [..]
>
>>> Back here in the real world, if programmers stopped writing silly code
>>> then there would be a lot fewer software problems to go around.
>>
>> Don't be silly.
>> The best solution does not involve magic.
>> Something like that will do:
>>
>> Signed overflow is implementation-defined, but in constrained way.
>
> I think that is what standard calls "unspecified behavior"

No, "unspecified behaviour" is entirely different.

Signed overflow is covered in 6.5p5:

"""
If an exceptional condition occurs during the evaluation of an
expression (that is, if the result is not mathematically defined or not
in the range of representable values for its type), the behavior is
undefined.
"""

"Unspecified behaviour" could mean (for example) that adding two ints
would always give you a valid int - it's just that you would not know
/which/ int you get if you had an overflow.

"Unspecified" is used for things like the order of evaluation for "a +
b" - it is unspecified which is evaluated first. (That means the
compiler doesn't need to document it - it doesn't even need to be
consistent from run to run.)

On 18/10/2021 15:48, Michael S wrote:
> On Monday, October 18, 2021 at 4:24:00 PM UTC+3, David Brown wrote:
>> On 18/10/2021 14:45, Michael S wrote:
>>> On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
>>
>>>> Back here in the real world, if programmers stopped writing silly code
>>>> then there would be a lot fewer software problems to go around.
>>>
>>> Don't be silly.
>>> The best solution does not involve magic.
>>> Something like that will do:
>>>
>>> Signed overflow is implementation-defined, but in constrained way.
>>> Possible options are
>>> 1. two-complement wrap-around
>>> 2. trap
>>> 3. saturation
>>> 4. one-complement wrap-around, if there exist a member of committee that care about it
>>> Implementation has to specify the chosen option clearly in documentation. It is allowed to select an option
>>> with special flag. It is not allowed to make option dependent on optimization settings.
>>> If the chosen option is trap and overflow happens in intermediate result of complex expression, but not in the final result than it's it's legal for trap to be intermittent and dependent on ether optimization level or phase of the moon, but not both.
>>>
>> That is not an attitude I would accept in a programmer working for me.
>> (I'd accept - and correct - ignorance. That's a different matter.)
>>
>> I will happily accept a trapping option as a temporary choice while
>> chasing a bug. I will happily accept specific behaviour, coded
>> /correctly/, in cases where specific behaviour is appropriate and
>> correct - in some algorithms, saturation is the desired behaviour, and
>> in a few cases modulo behaviour is the model you want. These can be
>> written correctly in C without any undefined behaviour, special flags,
>
> First, it is true that modulo is what I really want, but I leave other options open.
>

It is rarely a correct answer, except perhaps in a "shoot first, ask
questions later" style of programming.

> Second, I don't think that modulo behavior can be easily achieved in legalistic dialect of C.
> In "solutions" that I had seen there are rat hole near assignment of certain unsigned rvalues
> to signed lvalue and even bigger hole in handling of multiplication.

You use unsigned types - they are defined as modulo.

Yes, there are complications, especially if you have to deal with
unusual targets or write code that works correctly across different
sizes of int. Such code always needs care.

>
> Third, even if it's possible, there are other dimensions apart from legalism.
> One is aesthetic (it's ugly) and other is ergonomic (it's error prone).
>

Relying on wrapping is ugly and error-prone. It encourages people to
write code that makes no logical sense, such as adding two positive
numbers and checking for them being negative. It is error-prone, as it
leads people to think it is safe to take inputs from anywhere and use
them in any old way.

>
>> limited compilers, sacrificing of black cockerels, or whatever other
>> effort you make in order to make incorrect code give the results you want.
>>
>> But anyone who tells me that their own particular interpretation of what
>> happens on signed integer overflow is "the one right answer", "the
>> obvious choice", "the most efficient choice", "what C used to do", or
>> anything on that line - that person is going to have a hard time trying
>> to justify themselves. And if they tell me "it worked when I tried it",
>> I'll know their code reviews will take a lot longer.
>>
>> Coding is, for the most part, a matter of defining and calling functions
>> (as a general term, this includes operators). Every function has a
>> pre-condition that the caller ensures is true before calling the
>> function, and a post-condition that the function ensures is true before
>> returning. The function can - and generally must - assume the
>> pre-condition is true at the start of the function, just as the caller
>> can assume the post-condition is true at the return.
>>
>> Thus if you give the function appropriate inputs, you can expect the
>> desired output. If you give it invalid inputs, you can't have any
>> reasonable expectations about what comes out. Garbage in, garbage out.
>> It is the programmer's job to ensure that he or she does not put
>> garbage in.
>>
>> And in the case of signed integer arithmetic, it is the programmer's job
>> to ensure that the input to expressions will not cause an overflow. It
>> is /not/ the compiler's job to ensure that if garbage is put in, the
>> garbage that comes out should always smell of roses.
>>
>
> From a person that never complains about C Standard definition of "unsigned"
> that sounds more than a bit hypocritical.
>

On what basis do you assume I never complain about C's definition of
unsigned types and arithmetic? I have done so in the past, and no doubt
will do so again - letting your unsigned types wrap is also almost
always a mistake in the code. However, it is /sometimes/ useful to have
modulo behaviour in arithmetic - it's rare, but it happens. And thus it
is good that there is a way to get it in C. The way Ada copes with
this, by separating the concepts of range and modulo behaviour, is IMHO
nicer - there you can make the types you want, signed or unsigned,
modulo or not. But Ada has a more sophisticated type system than C, and
C's choices are a reasonable compromise within a simpler type system.

>>
>> You can argue until you are blue in the face that you think signed
>> integer arithmetic overflow /should/ be defined, whether you have a
>> particular idea for how it should be defined, or you just want it to do
>> "something". There are languages where it /is/ defined. In C, it is
>> /not/ defined. Accept that, or use a different language. End of story.
>
> I am not sure.
> It can be fixed in the future. The pressure is applied all the time and by far more influential people than myself.
>

The pressure is applied regularly, and regularly rejected by people who
are more influential, more experienced, and more knowledgeable than
either of us.

C++20, and now C23, has standardised on two's complement signed integer
representation. If ever there was a time to standardise a particular
type of signed integer overflow, that was the time. The relevant
proposals included such changes - polls were taken, and those parts were
soundly rejected.

A much better solution, IMHO, would be to standardise some pragmas that
let people decide these details themselves. Keep the status quo by
default - signed integer arithmetic has undefined overflow. But have a
standardised pragma that changes this, so that people who want
particular defined behaviour here can have it (just as there are
standardised pragmas for floating point rounding and a few other
floating point bits and pieces).

There could also be standardised versions of gcc's "overflow" builtins,
so that people could write their overflow checks in a sensible,
efficient and portable manner.

Niklas Holsti wrote:
> On 2021-10-17 21:14, EricP wrote:
>
>> I tried to compile this on Godbolt but gnat seems to be hardwired
>> that specs go in files with extension "ads" and bodies with "adb"
>> and there is no way to override it.
>
> That is a convention that makes normal ad-hoc use of GNAT very easy,
> compared to earlier Ada compilers which did not use a "source-based
> library" scheme as GNAT does.

Yeah. DEC VAX Ada83 had a code library database and management tool to
track between external file names and internal compiler assigned names.
It worked fine but just adds to the cost of compiler development.

So I understand the desire to avoid that route.

> The convention can be overridden - see chapter 10 in
> https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn.pdf. But Godbolt may
> not let you do that.

None of their options seem to work on Godbolt.

> Here is a single-file version of the program (where I also simplified
> the random initialization a bit). Interestingly, with this version I do
> get a significant slow-down with checks enabled (-gnato) as compared to
> checks suppressed (-gnatp), with about 11% increase in execution time
> when checks are enabled. Perhaps the compiler in-lines code in this
> version since it can see that MM.Do_MM is called only in one place.
>
> $ cat main_mm.adb
>
> with Ada.Numerics.Float_Random;
> with Ada.Real_Time;
> with Ada.Text_IO;
>
> procedure Main_MM
> is
>
> package MM is
>
> type Matrix is array (Positive range <>, Positive range <>) of Float;
>
> procedure Randomize (M : out Matrix);
>
> procedure Do_MM (A, B : in Matrix; C : in out Matrix)
> with Pre =>
> A'First(2) = B'First(1)
> and A'Last (2) = B'Last (1)
> and C'First(1) = A'First(1)
> and C'Last (1) = A'Last (1)
> and C'First(2) = B'First(2)
> and C'Last (2) = B'Last (2);
>
> end MM;
>
> package body MM is
>
> procedure Randomize (M : out Matrix)
> is
> use Ada.Numerics.Float_Random;
> Gen : Generator;
> begin
> Reset (Gen);
> for E of M loop
> E := Random (Gen);
> end loop;
> end Randomize;
>
> procedure Do_MM (A, B : in Matrix; C : in out Matrix)
> is
> begin
> for J in B'Range(2) loop
> for K in A'Range(2) loop
> for I in A'Range(1) loop
> C(I,J) := C(I,J) + A(I,K) * B(K,J);
> end loop;
> end loop;
> end loop;
> end Do_MM;
>
> end MM;
>
> use Ada.Real_Time;
>
> type Matrix_Ref is access MM.Matrix;
>
> A, B, C : Matrix_Ref := new MM.Matrix (1 .. 1000, 1 .. 1000);
>
> T1, T2: Time with Volatile;
>
> begin
>
> MM.Randomize (A.all);
> MM.Randomize (B.all);
> MM.Randomize (C.all);
>
> T1 := Clock;
> MM.Do_MM (A.all, B.all, C.all);
> T2 := Clock;
>
> Ada.Text_IO.Put_Line (Duration'Image (To_Duration (T2 - T1)));
>
> end Main_MM;

This works. Thanks.

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

> On 18/10/2021 14:59, clamky@hotmail.com wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
>>>> On 18/10/2021 01:47, Victor Yodaiken wrote:
>>>>> On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
>>>>>> On 17/10/2021 16:40, Victor Yodaiken wrote:
>>>>>>> On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
>>>>>>>
>>
>> [..]
>>
>>>> Back here in the real world, if programmers stopped writing silly code
>>>> then there would be a lot fewer software problems to go around.
>>>
>>> Don't be silly.
>>> The best solution does not involve magic.
>>> Something like that will do:
>>>
>>> Signed overflow is implementation-defined, but in constrained way.
>>
>> I think that is what standard calls "unspecified behavior"
>
> No, "unspecified behaviour" is entirely different.
>
> Signed overflow is covered in 6.5p5:
>
> """
> If an exceptional condition occurs during the evaluation of an
> expression (that is, if the result is not mathematically defined or not
> in the range of representable values for its type), the behavior is
> undefined.
> """
>
> "Unspecified behaviour" could mean (for example) that adding two ints
> would always give you a valid int - it's just that you would not know
> /which/ int you get if you had an overflow.

3.4.4
1
unspecified behavior
use of an unspecified value, or other behavior where this International Standard provides two or
more possibilities and imposes no further requirements on which is chosen in any instance
2
EXAMPLE An example of unspecified behavior is the order in which the
arguments to a function are evaluated.

Michael S provided four variants that are "acceptable" hence an attemt
at humor with "unspecified squared". You know you have failed when the
joke has to be explained.

>
> "Unspecified" is used for things like the order of evaluation for "a +
> b" - it is unspecified which is evaluated first. (That means the
> compiler doesn't need to document it - it doesn't even need to be
> consistent from run to run.)

clamky@hotmail.com writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 18/10/2021 14:59, clamky@hotmail.com wrote:
>>> Michael S <already5chosen@yahoo.com> writes:
>>>
>>>> On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
>>>>> On 18/10/2021 01:47, Victor Yodaiken wrote:
>>>>>> On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
>>>>>>> On 17/10/2021 16:40, Victor Yodaiken wrote:
>>>>>>>> On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
>>>>>>>>
[..]

>
> 3.4.4
> 1
> unspecified behavior
> use of an unspecified value, or other behavior where this
> International Standard provides two or
> more possibilities and imposes no further requirements on which is
> chosen in any instance
> 2
> EXAMPLE An example of unspecified behavior is the order in which the
> arguments to a function are evaluated.
>

[..]

And only now "... or more ..." really registered, i plead temporal
insanity. Sorry i was wrong. Guess this is a prime example of an ald
adage's:
Programmers are simpletons - they count one, two, many...

On Monday, October 18, 2021 at 11:14:33 AM UTC-5, David Brown wrote:

> Relying on wrapping is ugly and error-prone. It encourages people to
> write code that makes no logical sense, such as adding two positive
> numbers and checking for them being negative.

1. Signed arithmetic is a representation of arithmetic in the residue ring of the integers mod 2^{k}
2. Signed arithmetic is a patchy approximation of arithmetic over the integers with known failure cases and
unpredictable results and where the implication of x+1 > x and x <= INT_MAX is that INT_MAX < INT_MAX

Of course 1 makes no logical sense. Bravo!

Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
> On Monday, October 18, 2021 at 11:14:33 AM UTC-5, David Brown wrote:
>
>> Relying on wrapping is ugly and error-prone. It encourages people to
>> write code that makes no logical sense, such as adding two positive
>> numbers and checking for them being negative.
>

It seems that reminding you about USENET line breaking conventions
has little effect. I am beginning to suspect that this is rather
typical of you, it is certainly in line with your other attitudes.

I've inserted the line breaks for you (again).

> 1. Signed arithmetic is a representation of arithmetic in the
> residue ring of the integers mod 2^{k}

So, -1 is larger than 1 for signed integers?

On Monday, October 18, 2021 at 12:49:31 PM UTC-5, Thomas Koenig wrote:
> Victor Yodaiken <victor....@gmail.com> schrieb:
> > On Monday, October 18, 2021 at 11:14:33 AM UTC-5, David Brown wrote:
> >
> >> Relying on wrapping is ugly and error-prone. It encourages people to
> >> write code that makes no logical sense, such as adding two positive
> >> numbers and checking for them being negative.
> >
> It seems that reminding you about USENET line breaking conventions
> has little effect. I am beginning to suspect that this is rather
> typical of you, it is certainly in line with your other attitudes.
>
and i am not even embarrassed

> I've inserted the line breaks for you (again).
> > 1. Signed arithmetic is a representation of arithmetic in the
> > residue ring of the integers mod 2^{k}
> So, -1 is larger than 1 for signed integers?

There is no < relation in Z/2^kZ. The comparison is between the selected class
representatives INT_MIN ... INT_MAX
so INT_MAX+1 < INT_MAX which is a consequence both of the ring
structure and the operation of 2s complement arithmetic,
and x+1 > x is NOT a theorem. This model (a) is mathematically
consistent and (b) represents how 99% of modern processor architectures
do signed arithmetic.

On Monday, October 18, 2021 at 5:24:02 PM UTC+3, Tim Rentsch wrote:
> Michael S <already...@yahoo.com> writes:
>
> >> [..sarcastic comments regarding signed overflow..]
> > Don't be silly.
> > The best solution does not involve magic.
> > Something like that will do:
> >
> > Signed overflow is implementation-defined, but in constrained way.
> > Possible options are
> > 1. two-complement wrap-around
> > 2. trap
> > 3. saturation
> > 4. one-complement wrap-around, if there exist a member of
> > committee that care about it
> >
> > Implementation has to specify the chosen option clearly in
> > documentation. It is allowed to select an option with special
> > flag. It is not allowed to make option dependent on optimization
> > settings. If the chosen option is trap and overflow happens in
> > intermediate result of complex expression, but not in the final
> > result than it's it's legal for trap to be intermittent and
> > dependent on ether optimization level or phase of the moon, but
> > not both.
> My sense is this idea is not much better than how things are
> now. I would like to see the decision be under control of
> the source code, perhaps by means of a #pragma:
>
> #pragma STDC SIGNED_OVERFLOW WRAP
> #pragma STDC SIGNED_OVERFLOW TRAP
> #pragma STDC SIGNED_OVERFLOW SATURATE
> #pragma STDC SIGNED_OVERFLOW UNDEFINED
> (..others?..)
>
> If it's important, implementations might be allowed not to
> implement some or all of these choices; but if they don't then
> they must at least check the #pragma line for legality and fail
> the compilation if they cannot accommodate the choice indicated
> (or if the #pragma STDC doesn't scan for some reason).

I'd very much prefer if UNDEFINED is not in the list of Standard compliant options.
Compiler can offer it, but then it would have no right to identify as "standard C".
IMHO, UNDEFINED is only good to win specifically crafted benchmarks.

I agree with the rest of your suggestions.

Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
>>> [..sarcastic comments regarding signed overflow..]
>
>> Don't be silly.
>> The best solution does not involve magic.
>> Something like that will do:
>>
>> Signed overflow is implementation-defined, but in constrained way.
>> Possible options are
>> 1. two-complement wrap-around
>> 2. trap
>> 3. saturation
>> 4. one-complement wrap-around, if there exist a member of
>> committee that care about it
>>
>> Implementation has to specify the chosen option clearly in
>> documentation. It is allowed to select an option with special
>> flag. It is not allowed to make option dependent on optimization
>> settings. If the chosen option is trap and overflow happens in
>> intermediate result of complex expression, but not in the final
>> result than it's it's legal for trap to be intermittent and
>> dependent on ether optimization level or phase of the moon, but
>> not both.
>
> My sense is this idea is not much better than how things are
> now. I would like to see the decision be under control of
> the source code, perhaps by means of a #pragma:
>
> #pragma STDC SIGNED_OVERFLOW WRAP
> #pragma STDC SIGNED_OVERFLOW TRAP
> #pragma STDC SIGNED_OVERFLOW SATURATE
> #pragma STDC SIGNED_OVERFLOW UNDEFINED
> (..others?..)
>
> If it's important, implementations might be allowed not to
> implement some or all of these choices; but if they don't then
> they must at least check the #pragma line for legality and fail
> the compilation if they cannot accommodate the choice indicated
> (or if the #pragma STDC doesn't scan for some reason).

Gcc C already has the compiler switch -ftrapv to enable signed integer
overflow checks (operators are implemented as subroutine calls).

The problem with such pragmas in C is the same as compiler switches:
they cause many false positives (overflow traps) because they are too
much of a blunt object. As a consequence people just turn them off.

A number of studies of real world code have shown that it is a
mixture of signed and unsigned, checked and unchecked assumptions
*often within a single expression*.

E.g. these folks tap into clang's front end to inject checks into code.

Understanding Integer Overflow in C/C++, 2015
https://wdtz.org/files/tosem15.pdf

Consider a hypothetical line from a codec:

signal = signal + impulse[i + j];

In this expression, i+j are signed integers and should be added using
checked arithmetic, the array index then checked against array bounds,
the array element address addition calculated using unsigned modulo
arithmetic, and signal value added using saturating arithmetic.

Note also that some unsigned wrap arounds are bugs, some not.
It depends on the programmers intent.

This is why the VAX with it PSW global flag enabling overflow detect
had problems - real code would have to keep switching it on and off,
which would cause a large overhead so they just left it on for
Fortran or Ada and lived with occasional false overflow traps.
Which is why Alpha has separate instructions for Add and AddTrapOverflow.

The only mechanism I can think of that can handle that kind of
flexibility smoothly would be based on multiple language data types,
and an ISA with separate instructions for each operation on each type.

On 10/18/2021 2:23 PM, EricP wrote:
> Tim Rentsch wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>>> [..sarcastic comments regarding signed overflow..]
>>
>>> Don't be silly.
>>> The best solution does not involve magic.
>>> Something like that will do:
>>>
>>> Signed overflow is implementation-defined, but in constrained way.
>>> Possible options are
>>> 1. two-complement wrap-around
>>> 2. trap
>>> 3. saturation
>>> 4. one-complement wrap-around, if there exist a member of
>>>    committee that care about it
>>>
>>> Implementation has to specify the chosen option clearly in
>>> documentation.  It is allowed to select an option with special
>>> flag.  It is not allowed to make option dependent on optimization
>>> settings.  If the chosen option is trap and overflow happens in
>>> intermediate result of complex expression, but not in the final
>>> result than it's it's legal for trap to be intermittent and
>>> dependent on ether optimization level or phase of the moon, but
>>> not both.
>>
>> My sense is this idea is not much better than how things are
>> now.  I would like to see the decision be under control of
>> the source code, perhaps by means of a #pragma:
>>
>>     #pragma STDC SIGNED_OVERFLOW WRAP
>>     #pragma STDC SIGNED_OVERFLOW TRAP
>>     #pragma STDC SIGNED_OVERFLOW SATURATE
>>     #pragma STDC SIGNED_OVERFLOW UNDEFINED
>>     (..others?..)
>>
>> If it's important, implementations might be allowed not to
>> implement some or all of these choices;  but if they don't then
>> they must at least check the #pragma line for legality and fail
>> the compilation if they cannot accommodate the choice indicated
>> (or if the #pragma STDC doesn't scan for some reason).
>
> Gcc C already has the compiler switch -ftrapv to enable signed integer
> overflow checks (operators are implemented as subroutine calls).
>
> The problem with such pragmas in C is the same as compiler switches:
> they cause many false positives (overflow traps) because they are too
> much of a blunt object. As a consequence people just turn them off.
>
> A number of studies of real world code have shown that it is a
> mixture of signed and unsigned, checked and unchecked assumptions
> *often within a single expression*.
>
> E.g. these folks tap into clang's front end to inject checks into code.
>
> Understanding Integer Overflow in C/C++, 2015
> https://wdtz.org/files/tosem15.pdf
>
> Consider a hypothetical line from a codec:
>
>   signal = signal + impulse[i + j];
>
> In this expression, i+j are signed integers and should be added using
> checked arithmetic, the array index then checked against array bounds,
> the array element address addition calculated using unsigned modulo
> arithmetic, and signal value added using saturating arithmetic.
>
> Note also that some unsigned wrap arounds are bugs, some not.
> It depends on the programmers intent.
>
> This is why the VAX with it PSW global flag enabling overflow detect
> had problems - real code would have to keep switching it on and off,
> which would cause a large overhead so they just left it on for
> Fortran or Ada and lived with occasional false overflow traps.
> Which is why Alpha has separate instructions for Add and AddTrapOverflow.
>
> The only mechanism I can think of that can handle that kind of
> flexibility smoothly would be based on multiple language data types,
> and an ISA with separate instructions for each operation on each type.

As for example:
enumWithTraits(intNumEnums, overflowCode,
excepting,
modulo,
saturating,
widening
);
available in every kind of operation that can overflow?

Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
> On Monday, October 18, 2021 at 12:49:31 PM UTC-5, Thomas Koenig wrote:
>> Victor Yodaiken <victor....@gmail.com> schrieb:
>> > On Monday, October 18, 2021 at 11:14:33 AM UTC-5, David Brown wrote:
>> >
>> >> Relying on wrapping is ugly and error-prone. It encourages people to
>> >> write code that makes no logical sense, such as adding two positive
>> >> numbers and checking for them being negative.
>> >
>> It seems that reminding you about USENET line breaking conventions
>> has little effect. I am beginning to suspect that this is rather
>> typical of you, it is certainly in line with your other attitudes.
>>
> and i am not even embarrassed

A piece of advice, then. Not following the rules in a forum like
that will lead to people discarding your opinions out of hand,
they will start with the assumption that you are wrong; they
will only skip your arguments instead of taking them seriously.

If you are trying to convince anybody, that is not an effective
way to do it. If you are not trying to convince anybody, but
rather would like to stir up discussion for the sake of discussion,
then you're on the right track.

>
>> I've inserted the line breaks for you (again).
>> > 1. Signed arithmetic is a representation of arithmetic in the
>> > residue ring of the integers mod 2^{k}
>> So, -1 is larger than 1 for signed integers?
>
> There is no < relation in Z/2^kZ.

So it seems you are proposing to ban the "<" operator in C.
Excellent move.

Michael S <already5chosen@yahoo.com> writes:

> On Monday, October 18, 2021 at 5:24:02 PM UTC+3, Tim Rentsch wrote:
>
>> Michael S <already...@yahoo.com> writes:
>>
>>>> [..sarcastic comments regarding signed overflow..]
>>>
>>> Don't be silly.
>>> The best solution does not involve magic.
>>> Something like that will do:
>>>
>>> Signed overflow is implementation-defined, but in constrained way.
>>> Possible options are
>>> 1. two-complement wrap-around
>>> 2. trap
>>> 3. saturation
>>> 4. one-complement wrap-around, if there exist a member of
>>> committee that care about it
>>>
>>> Implementation has to specify the chosen option clearly in
>>> documentation. It is allowed to select an option with special
>>> flag. It is not allowed to make option dependent on optimization
>>> settings. If the chosen option is trap and overflow happens in
>>> intermediate result of complex expression, but not in the final
>>> result than it's it's legal for trap to be intermittent and
>>> dependent on ether optimization level or phase of the moon, but
>>> not both.
>>
>> My sense is this idea is not much better than how things are
>> now. I would like to see the decision be under control of
>> the source code, perhaps by means of a #pragma:
>>
>> #pragma STDC SIGNED_OVERFLOW WRAP
>> #pragma STDC SIGNED_OVERFLOW TRAP
>> #pragma STDC SIGNED_OVERFLOW SATURATE
>> #pragma STDC SIGNED_OVERFLOW UNDEFINED
>> (..others?..)
>>
>> If it's important, implementations might be allowed not to
>> implement some or all of these choices; but if they don't then
>> they must at least check the #pragma line for legality and fail
>> the compilation if they cannot accommodate the choice indicated
>> (or if the #pragma STDC doesn't scan for some reason).
>
> I'd very much prefer if UNDEFINED is not in the list of Standard
> compliant options. Compiler can offer it, but then it would have
> no right to identify as "standard C". IMHO, UNDEFINED is only
> good to win specifically crafted benchmarks.

I think it's necessary to have the option, to allow compatibility
with earlier versions of the C standard, and if the option is
possible there should be a way of explicitly selecting it. I very
much doubt I would ever select it myself, but at the same time I
think it's wrong to exclude it just because I personally don't like
it. And if there is someone who wants to make that choice, I would
much rather it be among the set of officially recognized features
than that it be some non-standard option or attribute or something
along those lines.

> I agree with the rest of your suggestions.

Agreement? I'm speechless. :)

On 18/10/2021 18:48, clamky@hotmail.com wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 18/10/2021 14:59, clamky@hotmail.com wrote:
>>> Michael S <already5chosen@yahoo.com> writes:
>>>
>>>> On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
>>>>> On 18/10/2021 01:47, Victor Yodaiken wrote:
>>>>>> On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
>>>>>>> On 17/10/2021 16:40, Victor Yodaiken wrote:
>>>>>>>> On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
>>>>>>>>
>>>
>>> [..]
>>>
>>>>> Back here in the real world, if programmers stopped writing silly code
>>>>> then there would be a lot fewer software problems to go around.
>>>>
>>>> Don't be silly.
>>>> The best solution does not involve magic.
>>>> Something like that will do:
>>>>
>>>> Signed overflow is implementation-defined, but in constrained way.
>>>
>>> I think that is what standard calls "unspecified behavior"
>>
>> No, "unspecified behaviour" is entirely different.
>>
>> Signed overflow is covered in 6.5p5:
>>
>> """
>> If an exceptional condition occurs during the evaluation of an
>> expression (that is, if the result is not mathematically defined or not
>> in the range of representable values for its type), the behavior is
>> undefined.
>> """
>>
>> "Unspecified behaviour" could mean (for example) that adding two ints
>> would always give you a valid int - it's just that you would not know
>> /which/ int you get if you had an overflow.
>
> 3.4.4
> 1
> unspecified behavior
> use of an unspecified value, or other behavior where this International Standard provides two or
> more possibilities and imposes no further requirements on which is chosen in any instance
> 2
> EXAMPLE An example of unspecified behavior is the order in which the
> arguments to a function are evaluated.
>
> Michael S provided four variants that are "acceptable" hence an attemt
> at humor with "unspecified squared". You know you have failed when the
> joke has to be explained.
>

OK, that makes a bit more sense. But it still wouldn't be unspecified
behaviour - Michael was looking for implementation defined behaviour
(i.e., the implementation would pick one way of handling overflow,
document it, and stick to it).

>
>>
>> "Unspecified" is used for things like the order of evaluation for "a +
>> b" - it is unspecified which is evaluated first. (That means the
>> compiler doesn't need to document it - it doesn't even need to be
>> consistent from run to run.)

On 18/10/2021 18:53, clamky@hotmail.com wrote:
> clamky@hotmail.com writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 18/10/2021 14:59, clamky@hotmail.com wrote:
>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>
>>>>> On Monday, October 18, 2021 at 2:12:34 PM UTC+3, David Brown wrote:
>>>>>> On 18/10/2021 01:47, Victor Yodaiken wrote:
>>>>>>> On Sunday, October 17, 2021 at 11:39:37 AM UTC-5, David Brown wrote:
>>>>>>>> On 17/10/2021 16:40, Victor Yodaiken wrote:
>>>>>>>>> On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:
>>>>>>>>>
> [..]
>
>>
>> 3.4.4
>> 1
>> unspecified behavior
>> use of an unspecified value, or other behavior where this
>> International Standard provides two or
>> more possibilities and imposes no further requirements on which is
>> chosen in any instance
>> 2
>> EXAMPLE An example of unspecified behavior is the order in which the
>> arguments to a function are evaluated.
>>
>
> [..]
>
> And only now "... or more ..." really registered, i plead temporal
> insanity. Sorry i was wrong. Guess this is a prime example of an ald
> adage's:
> Programmers are simpletons - they count one, two, many...
>

That's trolls, from the Discworld :-)

/Real/ programmers count 0, 1, 0, 1, 0, 1, ...

On 18/10/2021 19:00, Victor Yodaiken wrote:
> On Monday, October 18, 2021 at 11:14:33 AM UTC-5, David Brown wrote:
>
>> Relying on wrapping is ugly and error-prone. It encourages people to
>> write code that makes no logical sense, such as adding two positive
>> numbers and checking for them being negative.
>
> 1. Signed arithmetic is a representation of arithmetic in the residue ring of the integers mod 2^{k}

Not in standard C, and many other languages.

> 2. Signed arithmetic is a patchy approximation of arithmetic over the integers with known failure cases and
> unpredictable results and where the implication of x+1 > x and x <= INT_MAX is that INT_MAX < INT_MAX
>

Not in standard C, or any other language I know of. x + 1 is not
defined for x = INT_MAX, so it can have no implications.

> Of course 1 makes no logical sense. Bravo!
>

Try this exercise - find a random person, and ask them if "x + 1" is
always bigger than "x". Assuming you can make it past the "is this a
trick question?" stage, you'll get a "yes". C integer arithmetic
matches this.

Find another random person and ask them if they know what a residue ring
is. Ask them if they think ℤ/2ⁿ is a natural way to count and do
arithmetic. Ask them if they know why this is similar, but not
identical, to two's complement integers with wrapping. (Hint - think
about division.)

Ask them if they think a logical and natural numbering system should
follow basic rules of arithmetic as much as possible in the limited space.

Ask them if it makes more sense to say "these numbers are too big, you
can't add them", or if it is more sensible to say "these numbers are big
- you'll get a negative result if you add them".

Undefined signed integer overflow is the /only/ sensible and logical
choice. There is /no/ correct answer for overflowing arithmetic in any
simple, useful sense - so the sane way to handle it is to say "don't do
it". It's hardly the most difficult rule to follow.

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

> On 18/10/2021 18:53, clamky@hotmail.com wrote:
>> clamky@hotmail.com writes:

[..]

>
> That's trolls, from the Discworld :-)

Thanks! I've first encountered this adage (translated) an aen ago and it
stuck in my brain. However, it appears, you are also wrong [1] To make
this post NG topical - [1] points that Setun [2] was created by trolls,
not tame .no variety, but proper, fearless, soviet beasts.

>
> /Real/ programmers count 0, 1, 0, 1, 0, 1, ...

;)

[1] https://www.tes.com/teaching-resource/discworld-maths-starter-counting-in-troll-11027536
[2] https://en.wikipedia.org/wiki/Setun

On 18/10/2021 23:23, EricP wrote:
> Tim Rentsch wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>>> [..sarcastic comments regarding signed overflow..]
>>
>>> Don't be silly.
>>> The best solution does not involve magic.
>>> Something like that will do:
>>>
>>> Signed overflow is implementation-defined, but in constrained way.
>>> Possible options are
>>> 1. two-complement wrap-around
>>> 2. trap
>>> 3. saturation
>>> 4. one-complement wrap-around, if there exist a member of
>>>    committee that care about it
>>>
>>> Implementation has to specify the chosen option clearly in
>>> documentation.  It is allowed to select an option with special
>>> flag.  It is not allowed to make option dependent on optimization
>>> settings.  If the chosen option is trap and overflow happens in
>>> intermediate result of complex expression, but not in the final
>>> result than it's it's legal for trap to be intermittent and
>>> dependent on ether optimization level or phase of the moon, but
>>> not both.
>>
>> My sense is this idea is not much better than how things are
>> now.  I would like to see the decision be under control of
>> the source code, perhaps by means of a #pragma:
>>
>>     #pragma STDC SIGNED_OVERFLOW WRAP
>>     #pragma STDC SIGNED_OVERFLOW TRAP
>>     #pragma STDC SIGNED_OVERFLOW SATURATE
>>     #pragma STDC SIGNED_OVERFLOW UNDEFINED
>>     (..others?..)
>>
>> If it's important, implementations might be allowed not to
>> implement some or all of these choices;  but if they don't then
>> they must at least check the #pragma line for legality and fail
>> the compilation if they cannot accommodate the choice indicated
>> (or if the #pragma STDC doesn't scan for some reason).
>
> Gcc C already has the compiler switch -ftrapv to enable signed integer
> overflow checks (operators are implemented as subroutine calls).
>
> The problem with such pragmas in C is the same as compiler switches:
> they cause many false positives (overflow traps) because they are too
> much of a blunt object. As a consequence people just turn them off.

There are more problems than that. Consider "y = x + 3 - 2;". (Imagine
it is the result of a set of macros, or inline functions and constant
propagation, rather than a hand-written expression.) Can a compiler
change that to "y = x + 1;" with overflow checking there? Does it need
to do two operations, checking twice?

Requiring strict overflow trapping would cripple the performance of a
lot of code. That's fine for debugging (like gcc
"-fsanitize=signed-integer-overflow"), but not for normal code.

I believe that these days that "-ftrapv" is considered broken beyond
repair in gcc - it might work in some cases, but you'll get false
positives and false negatives and little in the way of guarantees of how
it interacts with optimisations and strength reductions. The sanitizer
is the modern way to handle this.

>
> A number of studies of real world code have shown that it is a
> mixture of signed and unsigned, checked and unchecked assumptions
> *often within a single expression*.
>
> E.g. these folks tap into clang's front end to inject checks into code.
>
> Understanding Integer Overflow in C/C++, 2015
> https://wdtz.org/files/tosem15.pdf
>
> Consider a hypothetical line from a codec:
>
>   signal = signal + impulse[i + j];
>
> In this expression, i+j are signed integers and should be added using
> checked arithmetic, the array index then checked against array bounds,
> the array element address addition calculated using unsigned modulo
> arithmetic, and signal value added using saturating arithmetic.
>
> Note also that some unsigned wrap arounds are bugs, some not.
> It depends on the programmers intent.
>
> This is why the VAX with it PSW global flag enabling overflow detect
> had problems - real code would have to keep switching it on and off,
> which would cause a large overhead so they just left it on for
> Fortran or Ada and lived with occasional false overflow traps.
> Which is why Alpha has separate instructions for Add and AddTrapOverflow.
>
> The only mechanism I can think of that can handle that kind of
> flexibility smoothly would be based on multiple language data types,
> and an ISA with separate instructions for each operation on each type.
>

For most ISA's, -ftrapv would generate some kind of "add with flags"
instruction followed by a "trap if overflow flag set". Some might do
the arithmetic with wider operands and then check the result. In
general, it's a costly business - and operations involving flags are
typically a pain for scheduling and pipelining on superscaler
processors. It's fine for bug-chasing, but not for efficient end products.

And then you have the trouble with mixing signed and unsigned operands,
as you mention. This is already quite counter-intuitive in C for many
people, as the operation is done as unsigned arithmetic. It is worse if
the programmer expected overflow trapping. (I like gcc's
"-Wsign-conversion" warning, but false positives are not uncommon.)

I think the only good answer here if you want tight control of your
overflows, is to switch from C. Ada will give you all sorts of
possibilities. Java will give you two's complement wrapping, fully
defined (thus no errors even when the results are wrong), for those that
want that. C++ lets you build classes to do exactly what you want,
whatever that may be.

But standardised pragmas would be a good step forward in C, IMHO.

On 19/10/2021 09:23, clamky@hotmail.com wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 18/10/2021 18:53, clamky@hotmail.com wrote:
>>> clamky@hotmail.com writes:
>
> [..]
>
>>
>> That's trolls, from the Discworld :-)
>
> Thanks! I've first encountered this adage (translated) an aen ago and it
> stuck in my brain. However, it appears, you are also wrong [1] To make
> this post NG topical - [1] points that Setun [2] was created by trolls,
> not tame .no variety, but proper, fearless, soviet beasts.
>

Many things, good and bad, can be said of the old Soviets - but they
were never afraid to try something different!

>>
>> /Real/ programmers count 0, 1, 0, 1, 0, 1, ...
>
> ;)
>
> [1] https://www.tes.com/teaching-resource/discworld-maths-starter-counting-in-troll-11027536
> [2] https://en.wikipedia.org/wiki/Setun
>

Thomas Koenig <tkoenig@netcologne.de> writes:
>If you are not trying to convince anybody, but
>rather would like to stir up discussion for the sake of discussion,
>then you're on the right track.

I don't think so. I am less likely to reply to a badly formatted
post, and I think others are, too.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>