On 23/07/2023 22:51, Malcolm McLean wrote:
> On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote:
>> David Brown <david...@hesbynett.no> writes:
>>
>>> Agreed. But it lets you have useful rules, leading to
simplification for
>>> both the compiler and the programmer. Knowing that as long as the
>>> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
>>> similar rules always holds true can be useful.
>> Interesting. Can you give an example where this rule helps a programmer
>> (and plain two's complement would not)?
>>
> I'm doing audio programming for my hobby project at the moment, so let's
> give a (hypothetical) audio problem. The 16 bit signed samples come
in with
> a DC bias (the average value, which should be zero), which
(unrealistically
> but not too unrealistically) is known at compile time.
>
> So
> #define DC_BIAS_CORRECTION 1
> #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION)
>
> if (dccorrect(pcm) > pcm)
> /* dc correction increases the value, take appropriate action) */
>
> So we've got if( n + 1 > n) in code, without the programmer writing
> any aburdity.
> Now what will the action be? Of course the code will be written for
32 bit machines,
> so it's
>
> int correctedpcm = dccorrect(pcm);
> if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16
bits */
> /* dc correction has caused the sample to overflow */
> correctedpcm = pcm; /* what can we do? Just reset to original
value and hope */
>
> Now with David Brown's scheme, when we move this code to a processor with
> 16 bit ints, the if() expression is undefined.

That's your problem: your task is expected to deal with values outside
of -32768/+32767, you need an int type that can represent that range.

(Although if samples are going to be 16-bit ones, then none of them will
be outside that range. Presumably the 16-bit code will have already
truncated them for you!)

This stuff can happen anyway: given WAV data with 16-bit sampling, if
you increase the volume slightly, or add together two lots of data, you
could overflow the range. Then either you clip or scale back down (or
apply complicated solutions to compress the range), but you will need
suitable numeric types that can represent the overflows.

Using int32 (even on the 16-bit device) will solve the problem. You
don't need it for the data, only for the calculations. (Just don't store
32-bit data truncated to 16-bit.)

So keep away from the problem areas at each end of an integer's bounds.

On Sunday, 23 July 2023 at 23:12:33 UTC+1, Bart wrote:
> On 23/07/2023 22:51, Malcolm McLean wrote:
> > On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote:
> >> David Brown <david...@hesbynett.no> writes:
> >>
> >>> Agreed. But it lets you have useful rules, leading to
> simplification for
> >>> both the compiler and the programmer. Knowing that as long as the
> >>> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
> >>> similar rules always holds true can be useful.
> >> Interesting. Can you give an example where this rule helps a programmer
> >> (and plain two's complement would not)?
> >>
> > I'm doing audio programming for my hobby project at the moment, so let's
> > give a (hypothetical) audio problem. The 16 bit signed samples come
> in with
> > a DC bias (the average value, which should be zero), which
> (unrealistically
> > but not too unrealistically) is known at compile time.
> >
> > So
> > #define DC_BIAS_CORRECTION 1
> > #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION)
> >
> > if (dccorrect(pcm) > pcm)
> > /* dc correction increases the value, take appropriate action) */
> >
> > So we've got if( n + 1 > n) in code, without the programmer writing
> > any aburdity.
> > Now what will the action be? Of course the code will be written for
> 32 bit machines,
> > so it's
> >
> > int correctedpcm = dccorrect(pcm);
> > if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16
> bits */
> > /* dc correction has caused the sample to overflow */
> > correctedpcm = pcm; /* what can we do? Just reset to original
> value and hope */
> >
> > Now with David Brown's scheme, when we move this code to a processor with
> > 16 bit ints, the if() expression is undefined.
> That's your problem: your task is expected to deal with values outside
> of -32768/+32767, you need an int type that can represent that range.
>
32768 is a bug. 32767 will also have the problem you mention. But it could be
32766 (for some reason we don't want the last value to be used). Then
it will work with 16 bit ints, under David Brown's scheme.

>

On 7/21/2023 1:03 PM, Chris M. Thomasson wrote:
> On 7/21/2023 1:24 AM, David Brown wrote:
>> On 20/07/2023 22:03, Chris M. Thomasson wrote:
>>> On 7/20/2023 2:38 AM, David Brown wrote:
>>>> On 19/07/2023 21:47, Ben Bacarisse wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> In 1982 I was 10 years old.  I was familiar with BASIC on at least
>>>> two different machines, but I didn't look at other languages for
>>>> another couple of years.  BCPL passed me by, as did Fortran and Algol.
>>> [...]
>>>
>>> Fwiw, In 1982 I was 5 years old and working with BASIC, LOGO and
>>> PILOT on my trusty Atari.
>>>
>>
>> I didn't see a computer until I was about 6 or 7 - a Commodore PET
>> (with dual tape drives!).
>
> I freaked out when my parents bought that Atari for me. They even got a
> cassette drive.

I did not sleep for several days!

On 23/07/2023 18:28, Bart wrote:
> On 23/07/2023 16:24, David Brown wrote:
> > On 22/07/2023 22:56, Ben Bacarisse wrote:
> > Similarly, I don't believe defining the behaviour of signed integer
> > arithmetic overflow actually helps anyone (other than occasional very
> > niche situations when you really do want modulo behaviour).  When you
> > overflow integer arithmetic, you get the wrong answer for pretty much
> > every situation.
>
> That's not true.
>
> INT_MAX + 1 - 1 will give the correct answer.

That's asking a completely different question - why would it be
surprising that you get a completely different answer?

> If you instead write it
> like this:
>
>     typedef unsigned int u32;
>     (int)((u32)INT_MAX + (u32)1 - (u32)1);
>

Unsigned arithmetic in C is defined as modulo arithmetic - again, a
totally different situation.

> then even C agrees that is well-behaved, despite probably performing
> exactly the same machine operations (where the compiler deigns to
> actually let it, that is, in actual code where variables are used and
> the steps are in different expressions)).
>

C is not, and never has been, defined in terms of any instructions it
might generate or the behaviour of any particular processor.

> So, it's possible to view most signed operations as though there were
> implicits casts to convert to unsigned and back again, for the purposes
> of making them well-defined in C. But then, why the need for an /any/ cast?
>

(A "cast" is an /explicit/ conversion. You mean "implicit conversions".)

Processors often provide different instructions that are similar in some
ways, and different in others. The same goes for languages. Some
languages only have one integer type, others have many.

A compiler (or compiler flags) aiming to help developers catch errors
will likely use different instructions for signed and unsigned
arithmetic - precisely because it aims to stop with an error message on
signed integer overflow.

> (Some operations will give different results between signed and
> unsigned, like shifts.)
>
>
> > I am at a loss as to why a predictable wrong answer is
> > an improvement over an unpredictable wrong answer - surely the aim of
> > the game is to avoid wrong answers in the first place.
>
> Are you talking about signed arithmetic here? Because your comments can
> equally to unsigned arithmetic.
>

I have always said that I think unsigned integer overflow is usually a
mistake too (except perhaps for the common use of "-1u"). But C defines
unsigned integer arithmetic to be modulo - whether I like it or not. (I
do like the language has /some/ way to get modulo arithmetic
efficiently, because it is /occasionally/ useful.)

But since we are talking about C and the way C is defined, I was
referring to signed arithmetic.

>
> >
> >> Making some arithmetic operations undefined results is a
> >> structure with no simple mathematical description.
> >
> > Agreed.  But it lets you have useful rules, leading to simplification
> > for both the compiler and the programmer.  Knowing that as long as the
> > programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
> > similar rules always holds true can be useful.
>
> > Of course, that means the programmer is responsible for ensuring that
> > "n" is not INT_MAX at that point in the code, and may have to take steps
> > to make sure of that.  But they must do so anyway, regardless of how
> > integer overflow is or is not defined, because the any definition would
> > almost certainly be wrong.
> >
> > So you lose nothing, and gain something, by having the behaviour
> undefined.
>
> I thought I'd try a test, and compiled one of my generated-C programs
> with both -O3 and -O3 -fwrapv, to see if there was actually any gain in
> performance due to taking advantage of UB.
>

And you think you'd show something here?

> (The program was an interpreter running a JPEG-decoder script.)
>
> Sure enough, I saw a 4% gain in performance, so that I'd have to admit
> that that would be handy...
>
> ... until I looked at the test results more carefully: the faster
> results were when compiled with -fwrapv, so integer overflow was not UB!
>
> Having well-defined wrapping behaviour was faster in this case (I only
> did one test). However the executable was slightly bigger by 0.25%.
>
> So, what I'd wanted to ask was, is the UB really worth it overall? What
> improvements you get purely with -fwrapv in general? As I showed I got a
> slight slowdown.
>

I think almost any case where "-fwrapv" produces faster code than
"-fno-wrapv" is either undefined behaviour in the source code, or a bug
(at least a "missed optimisation" issue) in the compiler. After all,
the compiler can freely use wrapping behaviour if it wants, and should
do so if it generates better code.

It is possible that /if/ you are writing code for which you actually
/want/ two's complement wrapping in your signed integer arithmetic (it
is very rare that this has any benefit, especially on modern processors
where using 64-bit integer types is faster, but it occasionally happens)
then you could find that using -fwrapv gives faster results than some
kinds of re-writing of your code. But since you can always convert back
and forth to unsigned types to get the same effect, I think it is unlikely.

On 23/07/2023 21:18, Bart wrote:
> On 23/07/2023 19:15, David Brown wrote:
> > On 23/07/2023 18:56, Bart wrote:
> >> How about talking about the C language as it is actually used by the
> >> majority of developers, rather than marginalising everyone in the 90%
> >> group where int actually is 32 bits and suggesting they are in the
> >> minority.
> >>
> >
> > I'm not marginalising anyone.  /You/ are.  No one is suggesting that
> > int's are always 16-bit - we are merely saying that the C language, in
> > theory and in practice, does not guarantee that ints are 32-bit.  It's
> > really quite a simple matter.
>
> The majority of people programming today will be using 32/64-bit
> machines, and using languages that have settled on 32/64-bit types,
> where that aspect has been exposed.
>

Yes, and no. The majority of modern general-purpose machines are
64-bit. But a great deal of programming is done with interpreted or
byte-coded languages, many of which have no fixed size for their
integers. Some have type names that have the size in the name, others
do not.

It is, however, fair to say that of the languages that have named
standard integer types that do not include a bit size in the type name,
C and C++ are the only popular ones where the size is not fixed. (So
where Scala, for example, has Byte, Short, Int and Long, the sizes are
the same on all platforms.)

When a new programming language is designed, it makes sense to pick the
standard integer size (if you have fixed integer sizes) based on
efficient sizes for the platforms you are targeting. If those platforms
all share a common size, picking that one size is appropriate. So if
anyone were making a new language targeting PC's today, it would be
silly to have anything other than 64-bit for their basic integers. And
if anyone were making a new language in around 1970, it would be silly
to have anything other than implementation-dependent choices of size
with a 16-bit minimum, just as C did. The computing world is more
consistent (and boring, perhaps) now than it was then.

> Including C. Since C is used in the OSes of those systems, in the APIs
> of countless libraries, and is used to implement or be the target of
> half those languages.

To the nearest percent, 0% of programmers are involved in coding for
operating systems or common libraries.

To the nearest percent, 100% of programmers access the API's of
libraries and OS's using bindings in the language they use to write
their code.

Almost every language makes it easy to make wrappers for accessing
external code in shared libraries. People making these wrappers will
need to understand the C sizes - people using them will not.

>
> But you are saying all those people above cannot assume a 32-bit int,
> because a small number of embedded C developers are using machines where
> the compiler has chosen a 16-bit type.

No, I never said any such thing - nothing even close to that.

I said that people talking about C in general should stick to the C
standards, and not make assumptions about particular implementations,
because real-world C implementations vary. I also said that if your C
code does not need to be portable, it can make non-portable assumptions.

>
> Presumably yours and Keith's advice, if they want to assume a 32-bit
> int, is to instead use a fixed-width type, or take their chances with
> 'long'.

I don't presume to guess Keith's advice, and /you/ should not presume
for anyone else either.

But you can look at my past posts and see - not presume - that I
personally use fixed-size types when I want a particular size, but that
other people doing other types of coding may have different preferences.

Sometimes it /is/ appropriate to assume that "int" is 32-bit for a
particular piece of coding (but not for discussions about the C language
- at least, not without stating the assumption explicitly). Sometimes
"int32_t" is better. Sometimes "int_fast32_t" is better. (For modern
processors, using "int_fast32_t" can often result in more efficient code.)

>
> OK, then why not advise those embedded developers against assuming `int`
> is 16 bits, because it could conceivably be 32 bits or even 64?
>

I would never advise an embedded programmer to assume "int" is 16-bit,
unless they were working on non-portable code for a target that they
knew had 16-bit int. Even then, I'd recommend using int16_t instead, or
putting in a static assertion on the size of int so that anyone later
trying to port the code to a different device would get a clear error.

> So nobody uses `int`; great result!

Great imaginary straw-man, you mean?

> It still leaves the problem of
> integer literals having a `int` type that now doesn't match their chosen
> alternative.

No, it does not.

Integer constants (since that is the correct term - "literal" is only
used for "string literal" in C) have a type suitable to hold the value.
The rules for the type of an integer constant are clearly given in the C
standards. As an exercise for the reader, I challenge you to look them
up and read them.

>
> I guess if somebody is really worried that a decade or two in the
> future, 'int' may change upwards (in my 4-decade career it's changed up
> once in C), or their application software might be ported to a PIC, they
> can use an assert.

I strongly recommend including static assertions in code whenever you
make assumptions about the platform that would render code incorrect if
it were reused on a different implementation.

Note - I recommend /static/ assertions, which fail at compile time.

On 23/07/2023 18:45, Kaz Kylheku wrote:
> On 2023-07-23, Bart <bc@freeuk.com> wrote:
>> On 23/07/2023 16:24, David Brown wrote:
>>> On 22/07/2023 22:56, Ben Bacarisse wrote:
>>> Similarly, I don't believe defining the behaviour of signed integer
>>> arithmetic overflow actually helps anyone (other than occasional very
>>> niche situations when you really do want modulo behaviour). When you
>>> overflow integer arithmetic, you get the wrong answer for pretty much
>>> every situation.
>>
>> That's not true.
>>
>> INT_MAX + 1 - 1 will give the correct answer. If you instead write it
>> like this:
>
> This is something the compiler can advantage of, regardless of
> whether the behavior is defined to the programmer.
>
> When we write a + 3 - c, then, if the compiler knows that the
> underlying target language has wrapping behavior with no ill
> consequences, it can rearrange the calculation to a - c + 3. (For
> whatever reason, such has having previously calculated a - c in another
> expression, and the consolidation of non-constant terms allows the
> result to be reused.)
>
> If overflow has negative/undefined consequences in the target language,
> then the rearrangement cannot be made; the programmer may have written
> the calculation in that order way on purpose, and verified that it
> doesn't overflow or underflow.
>
> (Speaking of "underlying target language", defined wrapping arithmetic
> can help writers of languages that translate to C, in the same way.)
>

If the compiler knows the target platform does not have something like
overflow exceptions, then it can rearrange "a + 3 - c" to "a - c + 3"
regardless of whether or not overflow is wrapping. Conversely, if the
platform does (or might) have overflow exceptions, then it cannot make
this re-arrangement regardless of whether overflow is wrapping or not.

Remember, treating integer overflow as wrapping is a plausible extension
to the semantics of the C language - it is not something that particular
hardware forces back up the chain to the compiler.

Compilers can take advantage of their knowledge of the overflow
behaviour of particular hardware instructions to optimise code -
regardless of any additional semantics they may or may not guarantee to
the programmer. Many processors have a range of different "add"
instructions - the compiler can pick one based on generated flags that
might be useful, or other characteristics.

On 24/07/2023 08:50, David Brown wrote:
> On 23/07/2023 21:18, Bart wrote:
>> Including C. Since C is used in the OSes of those systems, in the APIs
>> of countless libraries, and is used to implement or be the target of
>> half those languages.
>
> To the nearest percent, 0% of programmers are involved in coding for
> operating systems or common libraries.

Their APIs are usually expressed in C terms. I'm talking about Windows
and Linux. (MS tends to label many as 'C++' even when they are clearly C
only.)

This actually the reason why I first got involved with C at all: to be
able to use Windows.

>> But you are saying all those people above cannot assume a 32-bit int,
>> because a small number of embedded C developers are using machines
>> where the compiler has chosen a 16-bit type.
>
> No, I never said any such thing - nothing even close to that.

You said I was wrong to assume that 'int' in C implementations was
commonly 32 bits, and pointed out that the number of instances of
devices that are programmed using a C with 16-bit int outnumber all others.

But I think mainly you didn't like making that assumption when the C
standard, which has to cater for the lowest common denominator amongst
implementations, merely states that 'int' has to be 16 bits or more.

(At least it uses 16 and not something like 12 bits; I guess no one is
using the PDP8 any more.)

> I said that people talking about C in general should stick to the C
> standards, and not make assumptions about particular implementations,
> because real-world C implementations vary.

My point is, that mainly they don't. Not just within someone's personal
domain or experience, but often across a whole industry.

> I also said that if your C
> code does not need to be portable, it can make non-portable assumptions.

OK, good. My generated code is now only portable to machines like x64
and ARM64, and my manually written code includes also x86-32 and ARM32.
The chances are that it will also work on other 64-bit processors.

>> It still leaves the problem of integer literals having a `int` type
>> that now doesn't match their chosen alternative.
>
> No, it does not.
>
> Integer constants (since that is the correct term - "literal" is only
> used for "string literal" in C)

You're right, the C standard only uses that for string literals and
compound literals. But in the wider world, 'integer literal' is commonly
used to mean 'integer constant', including in this C++ reference:

https://en.cppreference.com/w/cpp/language/integer_literal

I use 'literal' in an even broader sense for all sorts of constructors
for floats, bignums, ranges, characters, records, lists and dicts.
Anywhere where you 'literally' enumerate the actual value(s), and it is
not hidden behind a name.

On Monday, 24 July 2023 at 10:59:06 UTC+1, Bart wrote:
> On 24/07/2023 08:50, David Brown wrote:
> > On 23/07/2023 21:18, Bart wrote:
> >> Including C. Since C is used in the OSes of those systems, in the APIs
> >> of countless libraries, and is used to implement or be the target of
> >> half those languages.
> >
> > To the nearest percent, 0% of programmers are involved in coding for
> > operating systems or common libraries.
> Their APIs are usually expressed in C terms. I'm talking about Windows
> and Linux. (MS tends to label many as 'C++' even when they are clearly C
> only.)
>
> This actually the reason why I first got involved with C at all: to be
> able to use Windows.
> >> But you are saying all those people above cannot assume a 32-bit int,
> >> because a small number of embedded C developers are using machines
> >> where the compiler has chosen a 16-bit type.
> >
> > No, I never said any such thing - nothing even close to that.
> You said I was wrong to assume that 'int' in C implementations was
> commonly 32 bits, and pointed out that the number of instances of
> devices that are programmed using a C with 16-bit int outnumber all others.
>
> But I think mainly you didn't like making that assumption when the C
> standard, which has to cater for the lowest common denominator amongst
> implementations, merely states that 'int' has to be 16 bits or more.
>
> (At least it uses 16 and not something like 12 bits; I guess no one is
> using the PDP8 any more.)
>
We once tendered for a job writing embedded software for a parking meter.
I was given the C compiler to help with the tender. It turned out that the chip
was very low powered, and int was only 8 bits. It also had no recursion and no
stack - local variables were simply put in global memory. However to its credit
it supported floating point - with three byte doubles.
When you're dealing with these tiny devices, the standard is sometimes a bit
of a dead letter.

Bart <bc@freeuk.com> writes:

> On 24/07/2023 08:50, David Brown wrote:

>> Integer constants (since that is the correct term - "literal" is only
>> used for "string literal" in C)
>
> You're right, the C standard only uses that for string literals and
> compound literals. But in the wider world, 'integer literal' is commonly
> used to mean 'integer constant', including in this C++ reference:
>
> https://en.cppreference.com/w/cpp/language/integer_literal

Yes, C++ calls them literals. But that site does use the same
terminology as the C standard when talking about C:

https://en.cppreference.com/w/c/language/integer_constant

I prefer C++'s usage, since "integer constant" can be so easily confused
for "integer constant expression".

It's hard to see what confusion would result from using literal in this
way for C as well -- except that you can't search for it in the C
standard.

--
Ben.

On 23/07/2023 23:10, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 22/07/2023 22:56, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 21/07/2023 17:14, Bart wrote:>
>>>
>>>>> C requires reduction of constant-expressions for compile-time
>>>>> expressions, and within conditional expressions of the preprocessor.
>>>>
>>>> Yes.
>>>>
>>>>> So the mechanism for doing that is already there; it is not optional.
>>>>
>>>> When you have a "constant expression" that is used wherever a "constant"
>>>> (what some people inaccurately call "integer literal") can be used, the
>>>> compiler must evaluate the expression at compile time. Apart from that, it
>>>> is all optional.
>>>>
>>>> Thus for "int x = 1 + 2;", the "1 + 2" must be evaluated at compile time
>>>> for a file-scope or static variable, but can be evaluated at run time if it
>>>> is a local variable.
>>> Objects with static storage duration are "initialized only once, prior
>>> to program startup". In any sane implementation, the calculation will
>>> be done by the compiler. But in principle the calculation and
>>> initialisation could be done by executable code that runs before main.
>>>
>>
>> Of course - compilers can do anything that gives the same observable
>> behaviour. The norm is that C toolchains put initialised static duration
>> data into a single section of the executable, with the initial values as a
>> binary section. Depending on the platform, either the initial data section
>> is loaded then made writeable, or is copied to writeable ram on startup.
>> But there is no requirement that it be done this way - merely a requirement
>> that it /could/ be done this way. (Unlike in C++, where statically
>> allocated data can have non-constant initialisation calculated at run-time
>> before main starts.)
>>
>>> <cut>
>>>>> In my languages and compilers, signed integer overflow has never been
>>>>> undefined. It's a choice.
>>>>>
>>>> A bad choice. Seriously. I mean, what kind of screwed up idea of numbers
>>>> do you have to have to think it's a good idea that adding two positive
>>>> numbers can give you a negative number?
>>> Two's complement numbers form a commutative ring. What's wrong with
>>> that?
>>
>> Nothing - but equally, it has no benefit. It gives nothing particularly
>> useful.
>
> There's nothing wrong with it but relies on a screwed up idea of
> numbers?

If you don't overflow your calculations, there's nothing wrong with
two's complement wrapping. But for most use of integer calculations, if
you overflow, something has gone wrong. Believing that a wrapped value
is somehow "correct" is - in most cases - a screwed up idea of numbers.

>
>> Now, if you were to redefine your multiplication and have your n-bit
>> numbers set up as a GF(2 ** n) finite field, you'd have some new useful
>> properties.
>
> It gives nothing particularly useful, but is the essential basis for
> something you describe as having new useful properties?
>

The properties of finite fields can be extremely useful, but only in a
very small area of coding. GF(8), for example, is critical to the
implementation of RAID 6. But since multiplication and division work
completely differently from normal integer arithmetic, having your
normal types work like finite fields would be very unhelpful for the
vast majority of coding.

My point is that having a neat mathematical description or certain
functionalities does not necessarily make a particular model for
fixed-size integers better than alternatives. Giving a mathematical
name to the model does not aid programmers or make incorrect code
correct - defined incorrect results are still wrong.

>> You'd be able to divide any integers, except for division by
>> 0, without any fractions. But would it be useful, other than for people
>> working on error correction algorithms? No, I don't believe so.
>
> That's because the special division operator is of narrow use. That's
> why it's not widely available in hardware.

Finite field division and multiplication is of narrow use, yes. (8-bit
support could easily be implemented in hardware, and would certainly be
useful, but bigger sizes would be very costly in hardware and very
little use in software.)

The main reason finite field arithmetic is not used for common integer
types is not about hardware implementation - it's that none of the
arithmetic operations (not just division) correspond to normal integer
arithmetic operations.

> But the operations that make
> two's complement numbers into a ring are widely available in hardware.
>

Lots of things are widely available in hardware but are not useful in
most software. The integer arithmetic instructions on x86 all set flags
such as carry and overflow, yet these are only useful in a small
proportion of cases (I'd guess under 10%). Most (though not all)
processors provide such flags, at least optionally. But the C language
does not provide access to these flags, despite them being available.

C is defined by the behaviour of the abstract machine, not
implementations. The abstract machine was designed with ease of
efficient implementation in mind, but the effect of hardware
instructions does not define the C language.

(Had the C language defined signed integers to have saturating overflow
behaviour, I believe that most modern processors would have saturating
arithmetic instructions. They'd still have wrapping ones, which are
useful at that level, but they'd have saturating instructions as well.)

>> Similarly, I don't believe defining the behaviour of signed integer
>> arithmetic overflow actually helps anyone (other than occasional very niche
>> situations when you really do want modulo behaviour).
>
> I think it can make reasoning about the programs easier.

I think the lack of signed integer overflow can make reasoning about
programs easier. (It's even easier if a language has no fixed size for
integers, but that's very hard to implement efficiently.)

>
>> When you overflow
>> integer arithmetic, you get the wrong answer for pretty much every
>> situation. I am at a loss as to why a predictable wrong answer is an
>> improvement over an unpredictable wrong answer - surely the aim of the game
>> is to avoid wrong answers in the first place.
>
> Yes, but you get the right answers by thinking clearly and understanding
> what the parts of a program do. I think that easier with plain two's
> complement arithmetic.
>

I disagree (to the second sentence - I obviously agree to the first). I
find if far easier to reason about arithmetic if I make sure my
calculations and types are such that overflow never occurs. Overflow
semantics, or lack thereof, are then not an issue - my integers behave
like simple plain mathematical integers.

There /are/ occasions where wrapping is useful. I have recently been
working on code with cascaded integrator-comb filters. The first
section of the filter are integrators which can increase without bound,
but the later differencing parts will decrease the correspondingly. So
to avoid working with very large numbers, you can do all the
calculations modulo any number that is bigger than a set size based on
the maximum value of the filter input and the number of filter steps.
The easiest and most common implementation is therefore to hold big
enough internal accumulators and use two's complement wrapping.

But it is easier to reason about the code and the filter if you do so
with unlimited size integers. Then you consider what happens if you add
"a_i * M" to the stages of the filter. You can see that as long as M is
big enough, the final output is the same as you get with unlimited
integer size, plus an integer multiple of M. This means you can do all
your arithmetic modulo M, and avoid overflows in your accumulators, and
it will work for any M that is big enough. This is all easier when
thinking about adding multiples of M, than specifically two's complement
wrapping of a particular size.

<https://en.wikipedia.org/wiki/Cascaded_integrator%E2%80%93comb_filter>

> From a practical point of view, where almost no one reasons about code
> any more and everyone replies on testing, you want well-defined
> semantics where overflow is trapped at run-time.

I /do/ like to reason about my code - though I very rarely do so in any
formal way. Notes on paper to convince myself that it /could/ be
formally proved is usually more than enough.

David Brown <david.brown@hesbynett.no> writes:
>On 23/07/2023 23:10, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:

>
>But I don't see well-defined overflow semantics as useful in any but a
>very small proportion of cases - I see /avoiding/ overflow as the
>critical point. And if you have made sure you arithmetic cannot
>overflow, what is the benefit in any given semantics for a situation
>that will not occur?
>
>I do agree that trapping overflow at run-time, especially during testing
>and debugging, is a useful tool. And that is one of the key reasons I
>see for /not/ defining the behaviour of integer overflow in the
>language, but leaving it clearly undefined. You cannot have the
>language define the behaviour of overflow as wrapping /and/ define it as
>trapping. If the language (or a particular implementation) says
>overflow must wrap, then it should not be trapping on overflow - that
>would be giving errors on correct (according to the language) code. A
>prime benefit of not defining overflow behaviour is that tools can help
>identify overflow errors with static checking or at run-time.
>
>But if the language defined the overflow as requiring trapping
>behaviour, it would need to define error handling systems (perhaps like
>C++ exceptions) requiring significant machinery, while also severely
>limiting optimisation through re-arrangement and simplification of
>arithmetic expressions (much more so than wrapping behaviour does).

There is a third possibility. The overflow is detected, an overflow
processor toggle is set, and the destination operand remains unchanged.

Software is free to check the overflow toggle after potentially
problematic operations, or simply ignore it if that provides the
required semantics.

That was how the Burroughs decimal machines worked - there was no
wrap of the destination operand, it would remain unchanged. Note
that the overflow toggle was sticky, so a series of calculations
could be made with overflow checked only once at the end. The
"branch on overflow" instruction would reset the processor overflow
toggle. Note also that the operand could be from one to 100 units
in length (either digits/nibbles or bytes - where the zone digit was
preserved but otherwise ignored) which, since arithmetic operations
were memory-to-memory (no registers), made it a bit tricky to detect
overflow before starting to write the destination operand[*].

The machine mainly ran COBOL.

[*] A rather clever algorithm that did addition/subtraction
starting with the most significant digits was developed
that still handled carry correctly. The representation
was either unsigned or signed-magnitude depending on the
operand address controller, with the sign occuping the
first (MSD) digit/nibble of a signed operand.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote:
>> David Brown <david...@hesbynett.no> writes:
>>
>> > Agreed. But it lets you have useful rules, leading to simplification for
>> > both the compiler and the programmer. Knowing that as long as the
>> > programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
>> > similar rules always holds true can be useful.
>> Interesting. Can you give an example where this rule helps a programmer
>> (and plain two's complement would not)?
>>
> I'm doing audio programming for my hobby project at the moment, so let's
> give a (hypothetical) audio problem. The 16 bit signed samples come in with
> a DC bias (the average value, which should be zero), which (unrealistically
> but not too unrealistically) is known at compile time.
>
> So
> #define DC_BIAS_CORRECTION 1
> #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION)

Scary! I'd prefer ((pcm) + DC_BIAS_CORRECTION).

> if (dccorrect(pcm) > pcm)
> /* dc correction increases the value, take appropriate action) */
>
> So we've got if( n + 1 > n) in code, without the programmer writing
> any aburdity.

Yes, with 32-bit int all is good. In modern C, you might want to use a
type that reflects the use you make of it. Here you might use
int_fast32_t for pcm but then your example would not have the bug your
are suggesting might be avoided by assuming that n+1 > n.

> Now what will the action be? Of course the code will be written for 32
> bit machines, so it's
>
> int correctedpcm = dccorrect(pcm);

Unless the corrected values are always in range (and surely your example
is for data that do not meet that criterion) the program's behaviour is
undefined from here on. It could stop right here with a signal. It
could play the Marseillaise...

> if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16 bits */
> /* dc correction has caused the sample to overflow */
> correctedpcm = pcm; /* what can we do? Just reset to original
> value and hope */

I'm confused. How can it be that a result > 32767 is not an overflow
for 16-bit samples?

> Now with David Brown's scheme, when we move this code to a processor
> with 16 bit ints, the if() expression is undefined.

With both "schemes" the if is well-defined and false (though it's too
late to matter with C's undefined overflow).

> But because it's
> UB, the compiler correctly guesses that we want it to be true.

The if is well-defined and false with either scheme. A good compiler
will tell you that the test is always false. On a system with 16-bit
int 32768 has type long and no int can test greater than 32768.

I don't see how this shows that assuming that n+1 > n is useful to
programmers. Something about your assumptions has led to some very odd
code.

Since UB has already occurred, the compiler can decide that the if test
(which is by any reasonable logic false) is in fact true! Though why
any compiler would do so is a mystery.

> Then
> the assignment is also UB (the dc_correct macro hasn't been written
> correctly), but it will do what we want. So ir works, With Ben's
> system (the commutative ring) the test return false, and it fails

Note that I am not suggesting that C should define integer arithmetic as
wrapping. In a language with wrapping integer arithmetic you could (and
should) program this differently, but in C you can't assume that you
/don't/ have wrapping arithmetic, so C's UB does not buy you much. And
assuming (as a programmer) that n+1 > n seems to only buy bugs.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

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

[behavior of signed integers on overflow]

>> Two's complement wrapping is a side-effect of efficient ALU
>> hardware implementation, nothing more. It's not something you
>> want in a language.
>
> I'd make the opposite argument. Making overflow undefined in C
> was a consequence of hardware that behaved that way, nothing more.
> It has found a niche in modern optimising compilers, but that's a
> side effect.

I have several reactions I would like to share.

One is that these two views are not quite opposites of each
other. Even if existing hardware was a motivation for making
integer overflow be undefined behavior, it might still be the
case that two's complement wrapping is not a good choice for
(exclusively) defining the behavior of integer arithmetic in a
programming language.

Two is that there may not have been hardware that misbehaved on
integer overflow, but possibly a motivation was a belief that
there _might be_ such hardware, either in the then-present or in
the then-future. I think it's possible (admittedly without having
any facts at my disposal) that all the then-known, then-existing
hardware did something "reasonable", even if the results might not
always be especially useful.

Three is that even if misbehaving hardware was /a/ motivation, it
might not have been the /only/ motivation (and indeed I expect
that there were other motivations besides the behavior of
existing hardware).

Four is that even if we accept that two's complement wrapping is a
reasonable choice for behavior on overflow, I'm not convinced it
should be the only choice. How about making what happens on
overflow be implementation defined, or under control of a #pragma?

Five is that behavior on overflow being undefined does offer an
advantage that implementation-defined behavior does not, in that
overflow would then be allowed to trigger a machine check and
crash the program. Having such a choice available (especially if
it could be selected by means of a #pragma) could be valuable in
some scenarios.

(The purist in me feels obliged to point out that any #pragma
generally is allowed to violate any required program semantics,
and so in that sense having overflow be UB is not necessary,
strictly speaking. Despite that it feels more honest to say
that overflow is undefined rather than implementation defined.)

My own view is that C would be improved if overflow were taken out
of the realm of just plain undefined behavior, but that limiting
the set of choices to just two's complement wrapping would be too
restrictive. It's very disappointing that the current C23 draft
has needlessly removed allowing representations other than two's
complement.

On Monday, 24 July 2023 at 17:22:56 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote:
> >> David Brown <david...@hesbynett.no> writes:
> >>
> >> > Agreed. But it lets you have useful rules, leading to simplification for
> >> > both the compiler and the programmer. Knowing that as long as the
> >> > programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
> >> > similar rules always holds true can be useful.
> >> Interesting. Can you give an example where this rule helps a programmer
> >> (and plain two's complement would not)?
> >>
> > I'm doing audio programming for my hobby project at the moment, so let's
> > give a (hypothetical) audio problem. The 16 bit signed samples come in with
> > a DC bias (the average value, which should be zero), which (unrealistically
> > but not too unrealistically) is known at compile time.
> >
> > So
> > #define DC_BIAS_CORRECTION 1
> > #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION)
> Scary! I'd prefer ((pcm) + DC_BIAS_CORRECTION).
It's deliberately buggy code to show how UB gets into real program written by
reasonably sensible but fallible people. If I put parentheses round the argument,
which is good practice, the the macro wouldn't expand to n + 1 > n, which was
what David Brown wanted.
> > if (dccorrect(pcm) > pcm)
> > /* dc correction increases the value, take appropriate action) */
> >
> > So we've got if( n + 1 > n) in code, without the programmer writing
> > any aburdity.
> Yes, with 32-bit int all is good. In modern C, you might want to use a
> type that reflects the use you make of it. Here you might use
> int_fast32_t for pcm but then your example would not have the bug your
> are suggesting might be avoided by assuming that n+1 > n.
>
Exactly.
> > Now what will the action be? Of course the code will be written for 32
> > bit machines, so it's
> >
> > int correctedpcm = dccorrect(pcm);
>
> Unless the corrected values are always in range (and surely your example
> is for data that do not meet that criterion) the program's behaviour is
> undefined from here on. It could stop right here with a signal. It
> could play the Marseillaise...
>
No, I think you've nodded here. Expressions are evaluated as ints. So if int
is 32 bits, a short + a constant could yield a value over 32767, without UB.
>
> > if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16 bits */
> > /* dc correction has caused the sample to overflow */
> > correctedpcm = pcm; /* what can we do? Just reset to original
> > value and hope */
> I'm confused. How can it be that a result > 32767 is not an overflow
> for 16-bit samples?
>
That was a mistake. correctedpcm is an int, so 32 bits on most machines.
However its going to be assigned to a 16 bit pcm sample (storing lots of
high order zero bytes in memory is too expensive), and at that point, it
could go over 32767, which we need to catch to prevent a nasty click in
our audio track. But > 32768 is wrong. > 32767 is right.
> > Now with David Brown's scheme, when we move this code to a processor
> > with 16 bit ints, the if() expression is undefined.
> With both "schemes" the if is well-defined and false (though it's too
> late to matter with C's undefined overflow).
> > But because it's
> > UB, the compiler correctly guesses that we want it to be true.
> The if is well-defined and false with either scheme. A good compiler
> will tell you that the test is always false. On a system with 16-bit
> int 32768 has type long and no int can test greater than 32768.
>
> I don't see how this shows that assuming that n+1 > n is useful to
> programmers. Something about your assumptions has led to some very odd
> code.
>
> Since UB has already occurred, the compiler can decide that the if test
> (which is by any reasonable logic false) is in fact true! Though why
> any compiler would do so is a mystery.
>
You're right. The example needs a bit more work to make it show a situation in
which assuming that x + 1 > x is an advantage.

On 24/07/2023 11:58, Bart wrote:
> On 24/07/2023 08:50, David Brown wrote:
> > On 23/07/2023 21:18, Bart wrote:
> >> Including C. Since C is used in the OSes of those systems, in the APIs
> >> of countless libraries, and is used to implement or be the target of
> >> half those languages.
> >
> > To the nearest percent, 0% of programmers are involved in coding for
> > operating systems or common libraries.
>
> Their APIs are usually expressed in C terms. I'm talking about Windows
> and Linux. (MS tends to label many as 'C++' even when they are clearly C
> only.)
>
> This actually the reason why I first got involved with C at all: to be
> able to use Windows.
>

When you write your own languages, or program in assembly, you are
responsible for everything. But people using Python, Rust, Java, C#,
TCL, or whatever, will use interface libraries in their language in
order to access the external shared libraries or OS calls.

> >> But you are saying all those people above cannot assume a 32-bit int,
> >> because a small number of embedded C developers are using machines
> >> where the compiler has chosen a 16-bit type.
> >
> > No, I never said any such thing - nothing even close to that.
>
> You said I was wrong to assume that 'int' in C implementations was
> commonly 32 bits, and pointed out that the number of instances of
> devices that are programmed using a C with 16-bit int outnumber all others.
>

No, I said it was wrong to write as though it was /always/ 32-bit.

> (At least it uses 16 and not something like 12 bits; I guess no one is
> using the PDP8 any more.)

No C (standard) implementation has ever used 12-bit int. 12-bit char,
sure, but not 12-bit int.

> >> It still leaves the problem of integer literals having a `int` type
> >> that now doesn't match their chosen alternative.
> >
> > No, it does not.
> >
> > Integer constants (since that is the correct term - "literal" is only
> > used for "string literal" in C)
>
> You're right, the C standard only uses that for string literals and
> compound literals. But in the wider world, 'integer literal' is commonly
> used to mean 'integer constant', including in this C++ reference:
>
>  https://en.cppreference.com/w/cpp/language/integer_literal

Read again what I wrote. In /C/, the term for things like 12345 is
"integer constant". This is described clearly in section 6.4.4, right
before the section on "string literals".

In /C++/, which sometimes uses significantly different terminology, the
concept of "literal" is far wider - it includes not only "string
literals" and "integer literals" but also user-define literals, and
"literal types".

The C++ reference you give, unsurprisingly, describes the C++ term. At
the bottom of the page under "See also", it has a link to "C
documentation for integer constant".

You have a habit of stubbornly resisting use of C standard terms,
despite posting in a C language group and discussing the C language. We
all know what you mean by "integer literal", but it still makes sense to
use the correct terms.

>
> I use 'literal' in an even broader sense for all sorts of constructors
> for floats, bignums, ranges, characters, records, lists and dicts.
> Anywhere where you 'literally' enumerate the actual value(s), and it is
> not hidden behind a name.
>

For your own language, that's fine - it's an appropriate choice of term.
The C term "constant" was picked before "const" was added to the
language, by which time it was too late to change to "literal".

But when you are discussing C, the correct term is "constant" (or
"integer constant" for integers).

On 24/07/2023 00:12, Bart wrote:
>
> On 23/07/2023 22:51, Malcolm McLean wrote:
> > On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote:
> >> David Brown <david...@hesbynett.no> writes:
> >>
> >>> Agreed. But it lets you have useful rules, leading to
> simplification for
> >>> both the compiler and the programmer. Knowing that as long as the
> >>> programmer hasn't made a mistake earlier in their code, "n + 1 > n"
> and
> >>> similar rules always holds true can be useful.
> >> Interesting. Can you give an example where this rule helps a programmer
> >> (and plain two's complement would not)?
> >>
> > I'm doing audio programming for my hobby project at the moment, so let's
> > give a (hypothetical) audio problem. The 16 bit signed samples come
> in with
> > a DC bias (the average value, which should be zero), which
> (unrealistically
> > but not too unrealistically) is known at compile time.
> >
> > So
> > #define DC_BIAS_CORRECTION 1
> > #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION)
> >
> > if (dccorrect(pcm) > pcm)
> >    /* dc correction increases the value, take appropriate action) */
> >
> > So we've got if( n + 1 > n) in code, without the programmer writing
> > any aburdity.
> > Now what will the action be? Of course the code will be written for
> 32 bit machines,
> > so it's
> >
> > int correctedpcm = dccorrect(pcm);
> > if (correctedpcm >  32768) /* not SHRT_MAX! Samples must fir in 16
> bits */
> >     /* dc correction has caused the sample to overflow */
> >       correctedpcm = pcm; /* what can we do? Just reset to original
> value and hope */
> >
> > Now with David Brown's scheme, when we move this code to a processor
> with
> > 16 bit ints, the if() expression is undefined.
>
> That's your problem: your task is expected to deal with values outside
> of -32768/+32767, you need an int type that can represent that range.
>

Exactly, yes. If you want arithmetic code to work, you need to use
types with a big enough range (or know for sure that you have modulo
arithmetic, and know for sure that modulo arithmetic is appropriate and
gives the right answers).

What you certainly can't do, as Malcolm seems to be suggesting, is see
how UB happens to be implemented on one system and assume it will be
implemented in the same way on another!

>
> So keep away from the problem areas at each end of an integer's bounds.
>

Yes.

On 24/07/2023 18:19, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 23/07/2023 23:10, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>
>>
>> But I don't see well-defined overflow semantics as useful in any but a
>> very small proportion of cases - I see /avoiding/ overflow as the
>> critical point. And if you have made sure you arithmetic cannot
>> overflow, what is the benefit in any given semantics for a situation
>> that will not occur?
>>
>> I do agree that trapping overflow at run-time, especially during testing
>> and debugging, is a useful tool. And that is one of the key reasons I
>> see for /not/ defining the behaviour of integer overflow in the
>> language, but leaving it clearly undefined. You cannot have the
>> language define the behaviour of overflow as wrapping /and/ define it as
>> trapping. If the language (or a particular implementation) says
>> overflow must wrap, then it should not be trapping on overflow - that
>> would be giving errors on correct (according to the language) code. A
>> prime benefit of not defining overflow behaviour is that tools can help
>> identify overflow errors with static checking or at run-time.
>>
>> But if the language defined the overflow as requiring trapping
>> behaviour, it would need to define error handling systems (perhaps like
>> C++ exceptions) requiring significant machinery, while also severely
>> limiting optimisation through re-arrangement and simplification of
>> arithmetic expressions (much more so than wrapping behaviour does).
>
> There is a third possibility. The overflow is detected, an overflow
> processor toggle is set, and the destination operand remains unchanged.
>

There are many more possibilities for defining overflow behaviour, but
that is certainly another one.

But if it is done strictly, it will still hinder optimisation and
simplification. "x + 1 - 1" could not be simplified to "x", since "x +
1" might set the toggle.

Trying to define overflow behaviour in such a way that this
simplification would be allowed, while an overflowing "x + 1" would set
the toggle, would be very difficult. I expect it could be done, but
you'd have the situation where significant observable behaviour depends
on optimisation details - a situation I would not like at all. You'd
have to treat things more like floating point, with very limited
expression simplification as the norm, and with something akin to gcc's
"-ffast-math" mode where you consider floating point operations to be
approximate and don't worry about small inaccuracies or variations.

> Software is free to check the overflow toggle after potentially
> problematic operations, or simply ignore it if that provides the
> required semantics.
>
> That was how the Burroughs decimal machines worked - there was no
> wrap of the destination operand, it would remain unchanged. Note
> that the overflow toggle was sticky, so a series of calculations
> could be made with overflow checked only once at the end. The
> "branch on overflow" instruction would reset the processor overflow
> toggle. Note also that the operand could be from one to 100 units
> in length (either digits/nibbles or bytes - where the zone digit was
> preserved but otherwise ignored) which, since arithmetic operations
> were memory-to-memory (no registers), made it a bit tricky to detect
> overflow before starting to write the destination operand[*].
>
> The machine mainly ran COBOL.
>
> [*] A rather clever algorithm that did addition/subtraction
> starting with the most significant digits was developed
> that still handled carry correctly. The representation
> was either unsigned or signed-magnitude depending on the
> operand address controller, with the sign occuping the
> first (MSD) digit/nibble of a signed operand.
>

On 2023-07-24, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 24/07/2023 08:50, David Brown wrote:
>
>>> Integer constants (since that is the correct term - "literal" is only
>>> used for "string literal" in C)
>>
>> You're right, the C standard only uses that for string literals and
>> compound literals. But in the wider world, 'integer literal' is commonly
>> used to mean 'integer constant', including in this C++ reference:
>>
>> https://en.cppreference.com/w/cpp/language/integer_literal
>
> Yes, C++ calls them literals. But that site does use the same
> terminology as the C standard when talking about C:
>
> https://en.cppreference.com/w/c/language/integer_constant
>
> I prefer C++'s usage, since "integer constant" can be so easily confused
> for "integer constant expression".

The term "literal constant" has a well-entrenched meaning in computer
science.

"literal" is a contraction of this, just like "deliverable" is short for
"deliverable goods" and what not.

"constant" is another contraction of "literal constant".

It's not such a good contraction compared to the other one because, as
you note, there are constant expressions that are not literals.

One kind of constant athat is not a literal is what you note:
a constant expression.

Another kinds of constant that is not a literal is a "symbolic
constant" a.k.a. "manifest constant". This is a symbolic name
arbitrarily given to a literal constant value.

Sometimes "constant" is used as the name of a class which includes
"literal constant" and "symbolic constant" to refer all of
them as a group.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> Four is that even if we accept that two's complement wrapping is a
> reasonable choice for behavior on overflow, I'm not convinced it
> should be the only choice. How about making what happens on
> overflow be implementation defined, or under control of a #pragma?

If it were implementation-defined, the choice of behavior would be made
based on what's easiest for the implementation, probably influenced by
the characteristics of the hardware. This wouldn't be particulary
useful for programmers. Putting it under control of a #pragma (or
perhaps an attribute of some kind of user-defined integer type) would
allow programmers to choose the behavior that's most useful for the
current application.

[...]

> My own view is that C would be improved if overflow were taken out
> of the realm of just plain undefined behavior, but that limiting
> the set of choices to just two's complement wrapping would be too
> restrictive. It's very disappointing that the current C23 draft
> has needlessly removed allowing representations other than two's
> complement.

I have the opposite reaction. There are, as far as I know, exactly
zero conforming C implementations that don't use two's complement,
and I don't believe that's likely to change. (There are perhaps
a handful of implementations that only conform to C90 or so; those
can continue to work as C90 implementations.) The standard already
imposes some restrictions on signed integer representations: they
must be binary, corresponding signed and unsigned types must use
the same representation for common values, and all-bits-zero must
be a representation for 0. I don't see that continued support
for sign and magnitude or ones' complement is any more useful than
hypothetical support for trinary or excess notation.

Do you see some concrete bad consequence of requiring two's
complement?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

> On 23/07/2023 23:10, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 22/07/2023 22:56, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 21/07/2023 17:14, Bart wrote:>
>>>>
>>>>>> C requires reduction of constant-expressions for compile-time
>>>>>> expressions, and within conditional expressions of the preprocessor.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> So the mechanism for doing that is already there; it is not optional.
>>>>>
>>>>> When you have a "constant expression" that is used wherever a "constant"
>>>>> (what some people inaccurately call "integer literal") can be used, the
>>>>> compiler must evaluate the expression at compile time. Apart from that, it
>>>>> is all optional.
>>>>>
>>>>> Thus for "int x = 1 + 2;", the "1 + 2" must be evaluated at compile time
>>>>> for a file-scope or static variable, but can be evaluated at run time if it
>>>>> is a local variable.
>>>> Objects with static storage duration are "initialized only once, prior
>>>> to program startup". In any sane implementation, the calculation will
>>>> be done by the compiler. But in principle the calculation and
>>>> initialisation could be done by executable code that runs before main.
>>>>
>>>
>>> Of course - compilers can do anything that gives the same observable
>>> behaviour. The norm is that C toolchains put initialised static duration
>>> data into a single section of the executable, with the initial values as a
>>> binary section. Depending on the platform, either the initial data section
>>> is loaded then made writeable, or is copied to writeable ram on startup.
>>> But there is no requirement that it be done this way - merely a requirement
>>> that it /could/ be done this way. (Unlike in C++, where statically
>>> allocated data can have non-constant initialisation calculated at run-time
>>> before main starts.)
>>>
>>>> <cut>
>>>>>> In my languages and compilers, signed integer overflow has never been
>>>>>> undefined. It's a choice.
>>>>>>
>>>>> A bad choice. Seriously. I mean, what kind of screwed up idea of numbers
>>>>> do you have to have to think it's a good idea that adding two positive
>>>>> numbers can give you a negative number?
>>>> Two's complement numbers form a commutative ring. What's wrong with
>>>> that?
>>>
>>> Nothing - but equally, it has no benefit. It gives nothing particularly
>>> useful.
>> There's nothing wrong with it but relies on a screwed up idea of
>> numbers?
>
> If you don't overflow your calculations, there's nothing wrong with two's
> complement wrapping.

If your calculation don't overflow, it's OK for them to do something
they won't do (wrap) because they don't overflow?

> But for most use of integer calculations, if you
> overflow, something has gone wrong. Believing that a wrapped value is
> somehow "correct" is - in most cases - a screwed up idea of numbers.

But I did not say that wrapped values should be believed to be correct.
You seemed to be saying that simply defining it to happen was a screwed
up notion of numbers.

> My point is that having a neat mathematical description or certain
> functionalities does not necessarily make a particular model for fixed-size
> integers better than alternatives. Giving a mathematical name to the model
> does not aid programmers or make incorrect code correct - defined incorrect
> results are still wrong.

But there are advantages to having defined incorrect answers over
undefined incorrect answers.

> C is defined by the behaviour of the abstract machine, not implementations.
> The abstract machine was designed with ease of efficient implementation in
> mind, but the effect of hardware instructions does not define the C
> language.

I am not talking about C. I was simply responding to the notion that
wrapping in based on a screwed-up notion of numbers.

>> Yes, but you get the right answers by thinking clearly and understanding
>> what the parts of a program do. I think that easier with plain two's
>> complement arithmetic.
>
> I disagree (to the second sentence - I obviously agree to the first). I
> find if far easier to reason about arithmetic if I make sure my
> calculations and types are such that overflow never occurs.

How can that be any harder if arithmetic wraps than if it undefined?
For one thing, undefined means it might wrap.

> Overflow
> semantics, or lack thereof, are then not an issue - my integers behave like
> simple plain mathematical integers.

So you don't care what happens on overflow. Yet you seem to say that
one choice for overflow behaviour makes this avoiding of overflow easier.

[Sorry, I cut an example that you might have taken great care in
choosing, but I could not immediately see its relevance. If that was a
mistake I apologise and I'll take a close look at it.]

>>> Agreed. But it lets you have useful rules, leading to simplification for
>>> both the compiler and the programmer. Knowing that as long as the
>>> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
>>> similar rules always holds true can be useful.
>> Interesting. Can you give an example where this rule helps a programmer
>> (and plain two's complement would not)?
>
> I don't think rules like this are going to be of much help directly to a
> programmer.

I re-worded your claim and I think that's led us off track again. You
did not say it helps, you said it can lead "to simplification for
.... the programmer". Can you give an example of this simplification?

>>> Even better, IMHO - when something is undefined behaviour, a compiler or
>>> debugging tool can consider it an error. That means you can use tools to
>>> help catch bugs in your code - static analysis of potential overflows, or
>>> run-time error handling. But if the behaviour is defined in some way, then
>>> it is not an error - the compiler has to assume that you intentionally
>>> wrapped your integers.
>>>
>>> I for one would rather have help getting my programs correct, than a
>>> language that blindly accepted all my mistakes.
>>
>> Tools should be to targeted at programmers. If there is a tool for C
>> that can detect signed arithmetic overflow, there should be one that can
>> detect wrapping in two's complement arithmetic. Maybe no one implements
>> such things, but that's not the fault of the language semantics.
>
> A tool that helps you find situations where your program acted correctly
> according to language semantics is not going to be very useful.

Yes, but why do you think of tools in that way? A tool that can help me
reason about correctness, about cache use, about memory use and
leaks and so on would be very useful. Any tool that does what you say
(help a programmer detect undefined integer overflow) should be able to
help a programmer detect defined integer wrapping.

> It would
> be possible to have a tool that logged particular correct behaviour, but I
> think it is more common and more useful for tools to log (and/or halt) on
> /incorrect/ behaviour.

It would be vastly more useful to have tools that helped to detect
incorrect behaviour as defined by the programmer and not just be the
language. The latter is very narrow; the former is at the heart of what
programming is.

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Monday, 24 July 2023 at 17:22:56 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote:
>> >> David Brown <david...@hesbynett.no> writes:
>> >>
>> >> > Agreed. But it lets you have useful rules, leading to simplification for
>> >> > both the compiler and the programmer. Knowing that as long as the
>> >> > programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
>> >> > similar rules always holds true can be useful.
>> >> Interesting. Can you give an example where this rule helps a programmer
>> >> (and plain two's complement would not)?
>> >>
>> > I'm doing audio programming for my hobby project at the moment, so let's
>> > give a (hypothetical) audio problem. The 16 bit signed samples come in with
>> > a DC bias (the average value, which should be zero), which (unrealistically
>> > but not too unrealistically) is known at compile time.
>> >
>> > So
>> > #define DC_BIAS_CORRECTION 1
>> > #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION)
>> Scary! I'd prefer ((pcm) + DC_BIAS_CORRECTION).
> It's deliberately buggy code to show how UB gets into real program written by
> reasonably sensible but fallible people. If I put parentheses round the argument,
> which is good practice, the the macro wouldn't expand to n + 1 > n, which was
> what David Brown wanted.
>> > if (dccorrect(pcm) > pcm)
>> > /* dc correction increases the value, take appropriate action) */
>> >
>> > So we've got if( n + 1 > n) in code, without the programmer writing
>> > any aburdity.
>> Yes, with 32-bit int all is good. In modern C, you might want to use a
>> type that reflects the use you make of it. Here you might use
>> int_fast32_t for pcm but then your example would not have the bug your
>> are suggesting might be avoided by assuming that n+1 > n.
>>
> Exactly.
>> > Now what will the action be? Of course the code will be written for 32
>> > bit machines, so it's
>> >
>> > int correctedpcm = dccorrect(pcm);
>>
>> Unless the corrected values are always in range (and surely your example
>> is for data that do not meet that criterion) the program's behaviour is
>> undefined from here on. It could stop right here with a signal. It
>> could play the Marseillaise...
>>
> No, I think you've nodded here. Expressions are evaluated as ints. So if int
> is 32 bits, a short + a constant could yield a value over 32767, without UB.

I mean when moved to the 16-bit machine. Is that not the whole point of
this example? There's no problem on 32-bits but you wanted to
illustrate how one scheme helped somehow in that move, but in that move
the undefined behaviour has occurred before the "if".

>> > if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16 bits */
>> > /* dc correction has caused the sample to overflow */
>> > correctedpcm = pcm; /* what can we do? Just reset to original
>> > value and hope */
>> I'm confused. How can it be that a result > 32767 is not an overflow
>> for 16-bit samples?
>>
> That was a mistake. correctedpcm is an int, so 32 bits on most machines.
> However its going to be assigned to a 16 bit pcm sample (storing lots of
> high order zero bytes in memory is too expensive), and at that point, it
> could go over 32767, which we need to catch to prevent a nasty click in
> our audio track. But > 32768 is wrong. > 32767 is right.

I thought the typo was > instead of >= since you'd make a lot of the
fact that SHRT_MAX is not what you wanted but one way or another, I
can't see what the example is suppose to show now.

>> > Now with David Brown's scheme, when we move this code to a processor
>> > with 16 bit ints, the if() expression is undefined.
>> With both "schemes" the if is well-defined and false (though it's too
>> late to matter with C's undefined overflow).
>> > But because it's
>> > UB, the compiler correctly guesses that we want it to be true.
>> The if is well-defined and false with either scheme. A good compiler
>> will tell you that the test is always false. On a system with 16-bit
>> int 32768 has type long and no int can test greater than 32768.
>>
>> I don't see how this shows that assuming that n+1 > n is useful to
>> programmers. Something about your assumptions has led to some very odd
>> code.
>>
>> Since UB has already occurred, the compiler can decide that the if test
>> (which is by any reasonable logic false) is in fact true! Though why
>> any compiler would do so is a mystery.
>>
> You're right. The example needs a bit more work to make it show a situation in
> which assuming that x + 1 > x is an advantage.

You think there is one? I would like to see it.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

[why not implementation-defined for signed integer overflow?]

> That would require documenting all the possible behaviours. I
> might have been left as undefined because no one was confident
> that they could list all the real-world choices that mattered.

It's not enough that all the possible behaviors be known; they
also must be describable in terms of what happens in the C
abstract machine. For example, suppose on machine X an integer
overflow causes all the bits of the program counter to be
inverted. As far as the hardware is concerned, that effect is
well defined, but there is no way to say what that means in a
way that makes sense in the context of the C abstract machine.
Because of that, the C standard must relegate such cases to the
realm of undefined behavior.

(I'm off on a few weeks holiday soon, which will greatly limit how much
I can read and post to Usenet. So if I don't answer you or other
posters in the near future, it is not through lack of interest.)

On 25/07/2023 03:42, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 23/07/2023 23:10, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>

<snip>

>>>>> Two's complement numbers form a commutative ring. What's wrong with
>>>>> that?
>>>>
>>>> Nothing - but equally, it has no benefit. It gives nothing particularly
>>>> useful.
>>> There's nothing wrong with it but relies on a screwed up idea of
>>> numbers?
>>
>> If you don't overflow your calculations, there's nothing wrong with two's
>> complement wrapping.
>
> If your calculation don't overflow, it's OK for them to do something
> they won't do (wrap) because they don't overflow?
>

Yes. If your calculations don't overflow, it doesn't matter what would
hypothetically happen if they had overflowed. That is how gcc (and a
number of other compilers) interpret undefined behaviour, and use it for
optimisation to give more efficient code on the assumption that the
calculations don't overflow.

My position is that overflowing calculations, on the whole, only occur
as a result of errors in the code. I want two things from my compiler -
help finding errors, and the most efficient code practically possible on
the assumption that the source code is correct. (I also like to be able
to change the balance between these using compiler flags.) UB on
overflow is a positive thing for both of these.

I can't see the point in a feature that - given a bug in my code leading
to overflow, goes out of its way to guarantee a particular type of
garbage out when it gets garbage in. By the time the program flow
reaches a point where two's complement wrapping is specifically
generated (rather than just by coincidence as the most efficient code
for arithmetic without wrapping semantics), the wrapping only applies if
the values were wrong from before.

>> But for most use of integer calculations, if you
>> overflow, something has gone wrong. Believing that a wrapped value is
>> somehow "correct" is - in most cases - a screwed up idea of numbers.
>
> But I did not say that wrapped values should be believed to be correct.
> You seemed to be saying that simply defining it to happen was a screwed
> up notion of numbers.
>

Fair point.

So your position here is that it is advantageous to have a definition of
the overflow behaviour, without any requirement for the result to be
"correct" in any sense?

Would you be equally happy (assuming the code performance was unchanged)
with different defined overflow behaviour? Options include a trap or
exception of some sort, a "non-signalling NaN" value, saturation, or an
unspecified value (that is, a valid member of the type, but with no
information about what value).

>> My point is that having a neat mathematical description or certain
>> functionalities does not necessarily make a particular model for fixed-size
>> integers better than alternatives. Giving a mathematical name to the model
>> does not aid programmers or make incorrect code correct - defined incorrect
>> results are still wrong.
>
> But there are advantages to having defined incorrect answers over
> undefined incorrect answers.
>

What are they?

This is something people often say, yet are rarely able to justify.

I've given reasons why having undefined behaviour is better than defined
incorrect answers (optimisation opportunities, and better debugging and
run-time checking options).

The most common reason I have seen for supporting "defined incorrect"
answers is to aid debugging (always a noble aim). The argument is that
outputting a consistent wrong answer makes it easier to find a bug and
confirm the fix. While I agree with that to some extent, in practice
the same thing happens with UB-based optimisation. In theory, a
compiler can use UB to generate code that gives the answer you expect on
most days but wipes your hard disk when run on Tuesday afternoon. But
in practice, compilers are deterministic and the code they generate is
deterministic - given the same inputs, you'll get consistent outputs,
with as much chance of this aiding your bug-hunting as you get from
having defined incorrect answers.

(The exception is when the "defined incorrect" behaviour is an immediate
halt with error, which could help you find the problem faster. Of
course, that's the option you have with UB - a compiler can offer flags
to have such behaviour during debugging.)

Another common reason for "defined incorrect" behaviour is to claim it
avoids making things worse by having predictable behaviour. The reality
is that this is simply not true. Once you have incorrect values, you
are outside the specifications of the expected behaviour of your code -
the consequences are unpredictable. Bugs and incorrect behaviour can
spread, or they can die away with minor inconvenience - this is
basically independent on whether the incorrect behaviour was defined or not.

A famous example of the consequences of integer overflow is found in the
original Civilisation game, with the AI leader Ghandi. The AI leaders
have, amongst their other characteristics, a "peacefulness" score from 0
(psychotic) to 255 (at one with the universe). Ghandi starts at maximum
peacefulness, and never attacks others. But once atomic weapons are
developed in the game, every leader gets a bit more cautious about
starting a war, and their peacefulness score is increased by 2. Due to
wrapping of an 8-bit number, Ghandi is now at 1 and immediately declares
nuclear war on everyone else.

So - why do /you/ think that defined incorrect behaviours are better
than undefined incorrect behaviours?

>> C is defined by the behaviour of the abstract machine, not implementations.
>> The abstract machine was designed with ease of efficient implementation in
>> mind, but the effect of hardware instructions does not define the C
>> language.
>
> I am not talking about C. I was simply responding to the notion that
> wrapping in based on a screwed-up notion of numbers.

OK. Let me instead suggest it is based on a different notion of numbers
from the ordinary everyday integers. And an approximation to the
ordinary everyday integers is what programmers are almost always trying
to get when they use standard integer types in programming.

Those of us with a more mathematical background or interests know the
concept of "number" can be very much wider, but it is rarely relevant
for general programming.

>
>>> Yes, but you get the right answers by thinking clearly and understanding
>>> what the parts of a program do. I think that easier with plain two's
>>> complement arithmetic.
>>
>> I disagree (to the second sentence - I obviously agree to the first). I
>> find if far easier to reason about arithmetic if I make sure my
>> calculations and types are such that overflow never occurs.
>
> How can that be any harder if arithmetic wraps than if it undefined?
> For one thing, undefined means it might wrap.

I want to reason about my code with /no/ overflows. Any behaviour on
overflow is hypothetical.

To me, giving a definition to some behaviour means people will expect
particular behaviour.

I might specify a function like this :

// Precondition: abs(x) <= sqrt(INT_MAX)
// Postcondition: result = x^2
int square(int x);

If we wanted to specify defined two's complement wrapping behaviour (for
32-bit int), we could change the post condition to:

// Postcondition: result = (x^2 + 2^31) mod 2^32 - 2^31

This is not nearly as nice to reason about. And some people would
assume this holds for input values that do not satisfy the pre-condition.

Leaving out any possibility or definition for overflow behaviour keeps
it all simpler and clearer.

>
>> Overflow
>> semantics, or lack thereof, are then not an issue - my integers behave like
>> simple plain mathematical integers.
>
> So you don't care what happens on overflow. Yet you seem to say that
> one choice for overflow behaviour makes this avoiding of overflow easier.
>

I am not asking for a particular choice of overflow behaviour - I am
asking for /no/ choice of overflow behaviour. I prefer to say that
overflow doesn't happen. Part of my job as a programmer is to ensure
that this is the case. And if overflow does not happen, then any
discussion of what happens if it does happen, is an irrelevant
distraction and waste of effort, and can lead both programmers and
compilers to poorer quality results.

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

> (I'm off on a few weeks holiday soon, which will greatly limit how much I
> can read and post to Usenet. So if I don't answer you or other posters in
> the near future, it is not through lack of interest.)
>
>
>
> On 25/07/2023 03:42, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 23/07/2023 23:10, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>
> <snip>
>
>>>>>> Two's complement numbers form a commutative ring. What's wrong with
>>>>>> that?
>>>>>
>>>>> Nothing - but equally, it has no benefit. It gives nothing particularly
>>>>> useful.
>>>> There's nothing wrong with it but relies on a screwed up idea of
>>>> numbers?
>>>
>>> If you don't overflow your calculations, there's nothing wrong with two's
>>> complement wrapping.
>> If your calculation don't overflow, it's OK for them to do something
>> they won't do (wrap) because they don't overflow?
>>
>
> Yes. If your calculations don't overflow, it doesn't matter what would
> hypothetically happen if they had overflowed.

I know that is what you said, but you, apparently, don't see why I think
that saying "it's screwed up" and then "there's nothing wrong with it"
and explaining that with "there's nothing wrong with it if it never
happens" leaves me confused. All I can conclude is that you /do/ think
it's screwed up because there's only nothing wrong with it if it doesn't
happen. Could you not just have stuck with the "it's screwed up" and
left out the intermediate "there's nothing wrong with it"?

> That is how gcc (and a
> number of other compilers) interpret undefined behaviour, and use it for
> optimisation to give more efficient code on the assumption that the
> calculations don't overflow.
>
> My position is that overflowing calculations, on the whole, only occur as a
> result of errors in the code.

That's true in C. But in a language with defined wrapping of integer
arithmetic, such overflows might simply result from after the fact
tests. In C one writes

if (this will overflow) {
report error or whatever
}
else do calculation

With wrapping one can sometimes write

do calculation
if (it overflowed) {
report error or whatever
}

Here, overflow is "not correct" but it's not a programming error in the
sense you mean.

> I want two things from my compiler - help
> finding errors, and the most efficient code practically possible on the
> assumption that the source code is correct. (I also like to be able to
> change the balance between these using compiler flags.) UB on overflow is
> a positive thing for both of these.

That seems to be all one has, even toady. In the 80s, I looked forward
to a world where a programmer's workbench would include tools to help
verify all sorts of program properties.

How do you use a compiler to help find overflow errors? Just compile
with something like -fsanitize=undefined and do lots of testing? If so,
there's no reason a compiler for a language with wrapping arithmetic
could not be just as helpful by do something similar for overflow,
despite it not being defined. In fact I've wanted to have an unsigned
version of gcc's -ftrapv more than once.

As for optimising, I don't know enough to know how much UB helps C. man
gcc says, for example, that -fwrapv "enables some optimizations and
disables others" so it's not as simple as you make out.

> I can't see the point in a feature that - given a bug in my code leading to
> overflow, goes out of its way to guarantee a particular type of garbage out
> when it gets garbage in. By the time the program flow reaches a point
> where two's complement wrapping is specifically generated (rather than just
> by coincidence as the most efficient code for arithmetic without wrapping
> semantics), the wrapping only applies if the values were wrong from before.
>
>>> But for most use of integer calculations, if you
>>> overflow, something has gone wrong. Believing that a wrapped value is
>>> somehow "correct" is - in most cases - a screwed up idea of numbers.
>> But I did not say that wrapped values should be believed to be correct.
>> You seemed to be saying that simply defining it to happen was a screwed
>> up notion of numbers.
>>
>
> Fair point.
>
> So your position here is that it is advantageous to have a definition of
> the overflow behaviour, without any requirement for the result to be
> "correct" in any sense?
>
> Would you be equally happy (assuming the code performance was unchanged)
> with different defined overflow behaviour? Options include a trap or
> exception of some sort, a "non-signalling NaN" value, saturation, or an
> unspecified value (that is, a valid member of the type, but with no
> information about what value).

To be honest, that's hard to say. I've not used languages with enough
of those options to make an informed comment.

>>> My point is that having a neat mathematical description or certain
>>> functionalities does not necessarily make a particular model for fixed-size
>>> integers better than alternatives. Giving a mathematical name to the model
>>> does not aid programmers or make incorrect code correct - defined incorrect
>>> results are still wrong.
>>
>> But there are advantages to having defined incorrect answers over
>> undefined incorrect answers.
>
> What are they?
>
> This is something people often say, yet are rarely able to justify.

Maybe the problem is partly the words. For example, testing for
overflow at run time can be easier with a defined incorrect result.

Another comes from the simplicity of defining the semantics of + (and -
and * and so on). Having a+b be the sum of a+b or "bottom" is messier
than having it be (a+b) mod 2^width. (It's not the usual mod, it's a
biased one, but that does not really complicate matters too much.)

Finally, there are cases that just don't need much thought. In BCPL one
writes (wrote?)

LET mid = (low + high) / 2

and there's no need to worry about overflow.

> I've given reasons why having undefined behaviour is better than defined
> incorrect answers (optimisation opportunities, and better debugging and
> run-time checking options).

I will defer to you about the optimisation, but if you have a citation
comparing the opportunities given by the two definitions I would really
like to take a look. However, nothing in having defined wrapping
prevents good debugging and run-time checking options except a narrow
view of what one considers to be the compiler's job. As I said, I've
wanted -ftrapv for unsigned arithmetic before now, ideally configurable
in the source because you don't always want it everywhere.

> The most common reason I have seen for supporting "defined incorrect"
> answers is to aid debugging (always a noble aim). The argument is that
> outputting a consistent wrong answer makes it easier to find a bug and
> confirm the fix. While I agree with that to some extent, in practice the
> same thing happens with UB-based optimisation. In theory, a compiler can
> use UB to generate code that gives the answer you expect on most days but
> wipes your hard disk when run on Tuesday afternoon. But in practice,
> compilers are deterministic and the code they generate is deterministic -
> given the same inputs, you'll get consistent outputs, with as much chance
> of this aiding your bug-hunting as you get from having defined incorrect
> answers.

Yes, I see no advantage there either way.

> (The exception is when the "defined incorrect" behaviour is an immediate
> halt with error, which could help you find the problem faster. Of course,
> that's the option you have with UB - a compiler can offer flags to have
> such behaviour during debugging.)
>
> Another common reason for "defined incorrect" behaviour is to claim it
> avoids making things worse by having predictable behaviour. The reality is
> that this is simply not true. Once you have incorrect values, you are
> outside the specifications of the expected behaviour of your code - the
> consequences are unpredictable. Bugs and incorrect behaviour can spread,
> or they can die away with minor inconvenience - this is basically
> independent on whether the incorrect behaviour was defined or not.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>David Brown <david.brown@hesbynett.no> writes:
>

>>
>> My position is that overflowing calculations, on the whole, only occur as a
>> result of errors in the code.
>
>That's true in C. But in a language with defined wrapping of integer
>arithmetic, such overflows might simply result from after the fact
>tests. In C one writes
>
> if (this will overflow) {
> report error or whatever
> }
> else do calculation
>
>With wrapping one can sometimes write
>
> do calculation
> if (it overflowed) {
> report error or whatever
> }
>
>Here, overflow is "not correct" but it's not a programming error in the
>sense you mean.

Overflow might actually "be correct", I just wrote such code last week.

Simulating a microcontroller countdown timer - when it wraps, an
exception needs to be generated and the timer register is reloaded.